Re: [Qemu-devel] [PATCH 01/29] target-sparc: don't trap on MMU-fault if MMU is disabled

[Artyom Tarasenko]

On Tue, Oct 11, 2016 at 4:50 PM, Richard Henderson <address@hidden> wrote:
> On 10/11/2016 09:00 AM, Artyom Tarasenko wrote:
>>
>> On Mon, Oct 10, 2016 at 11:14 PM, Richard Henderson <address@hidden>
>> 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