On Tue, Oct 11, 2016 at 4:50 PM, Richard Henderson <r...@twiddle.net> wrote:
> On 10/11/2016 09:00 AM, Artyom Tarasenko wrote:
>>
>> On Mon, Oct 10, 2016 at 11:14 PM, Richard Henderson <r...@twiddle.net>
>> wrote:
>>>
>>> On 10/01/2016 05:05 AM, Artyom Tarasenko wrote:
>>>>
>>>>
>>>> if (is_exec) {
>>>> - helper_raise_exception(env, TT_CODE_ACCESS);
>>>> + if (env->lsu & (IMMU_E)) {
>>>> + helper_raise_exception(env, TT_CODE_ACCESS);
>>>> + }
>>>> } else {
>>>> - helper_raise_exception(env, TT_DATA_ACCESS);
>>>> + if (env->lsu & (DMMU_E)) {
>>>> + helper_raise_exception(env, TT_DATA_ACCESS);
>>>> + }
>>>
>>>
>>>
>>> The cpu really does no kind of machine check for a hypervisor write to
>>> 0x1122334455667788?
>>
>>
>> A bare metal machine would raise Real Translation Exception. But since
>> we don't do real addresses...
>
>
> I was asking about an errant access from the hypervisor itself. I would
> have thought the guest running without an mmu would be running with real
> addresses, but the hypervisor itself would be running in physical addresses.
>
> But that said, we can't just let the access go completely unreported,
> surely. We can think as if we do real addresses, but with a 1-1 mapping to
> physical. So at least for !cpu_hypervisor_mode(env), a Real Translation
> Exception would seem to be totally justified.
Good point. data_access_error/instruction_access_error shall happen
in the hypervisor mode, otherwise it shall be data_real_translation_miss /
instruction_real_translation_miss.
Will change it, thanks.
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
