qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 12/25] target-sparc: Add MMU_REAL_IDX
Date: Fri, 15 Jan 2016 10:03:24 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

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.

> (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.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]