Re: [Qemu-devel] [PATCH 12/25] target-sparc: Add MMU_REAL_IDX

[Artyom Tarasenko]

On Fri, Jan 15, 2016 at 7:03 PM, Richard Henderson <address@hidden> wrote:
> On 01/15/2016 05:17 AM, Artyom Tarasenko wrote:
>> Hi Richard,
>>
>> please ignore my 2 previous mails: I've misread the commit message.
>> The actual problem and a possible solution below.
>>
>> On Thu, Dec 17, 2015 at 9:57 PM, Richard Henderson <address@hidden> wrote:
>>> This gives us a trivial way to access physical addresses
>>> (aka "real addresses", in sun4v terminology)
>>
>> In sun4v terminology "real address" is not "physical addresses".
>> There is just one more level of translation:
>> VA->RA->PA
>> which it's only visible from the hypervisor mode.
>
> Correct, but...
>
>> With MMU_REAL_IDX renamed to MMU_PHYS_IDX, I think we are fine.
>
> ... no.  REAL is currently implemented as PHYS, true, but that's only because
> we don't actually implemnet sun4v.
>
> If we ever properly implement a sun4v platform, we will implement the bulk of
> the hypervisor within qemu itself, for speed.  At which point REAL will in 
> fact
> undergo that final layer of translation exactly as expected.
>
> I think the naming is exactly correct, for the current sun4u implementation.

But sun4u has neither real mode nor any ASI having "real" as a part of
its name, no?

>> (As I was reading this patch the last time, I thought the plan was to
>> use the MMU_REAL_IDX for both real and physical accesses, hence the
>> confusion. But using one index for two modes would have been a bad
>> idea because we'd have to flush the translations every time we switch
>> to/from hypervisor mode which is too often).
>
> And that is exactly why hypervisor mode would not be implemented like you
> think, but within qemu itself.

In my case it is sort of implemented it like I think: few years back
I've implemented
its subset (incomplete but capable to boot the OpenSPARC firmware)
and have been trying to merge it with your work. :-)

I thought it is much easier to implement the RA translation than the hypervisor,
but maybe implementing the hypervisor is not as complex as I thought.

Indeed, your variant would be more performant.
In any case it looks like an interesting challenge.

I'd still prefer to call it MMU_PHYS_IDX for now and rename it once
the hypervisor layer is implemented.
But I'm not insisting on the naming. The naming issues are always hard. :-)

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu