On Fri, Jan 15, 2016 at 7:03 PM, Richard Henderson <r...@twiddle.net> 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 <r...@twiddle.net> 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
