Re: [Xen-devel] [RFC PATCH 4/4] arm/mem_access: Add software guest-page-table walk

[Julien Grall <julien.grall@xxxxxxx>]

On 09/05/2017 17:45, Tamas K Lengyel wrote:
> On Tue, May 9, 2017 at 10:22 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > On 09/05/17 17:04, Tamas K Lengyel wrote:
> > > On Tue, May 9, 2017 at 2:09 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > > > On 05/09/2017 08:17 AM, Sergej Proskurin wrote:
> > > > > Hi,
> > > > >
> > > > > > > What you currently do is try gva_to_ipa and if it does not work >> you
> > > > > > > will call p2m_gva_to_ipa. This sounds a bit pointless to me and
> > > > > > > waste of time if the underlying memory of stage-1 page table is >>
> > > > >
> > > > > protected. > > But we don't know that the stage-1 page table is
> > > > > protected until the > hardware based lookup fails. I can turn your
> > > > > argument around and say > doing the software based lookup is pointless
> > > > > and a waste of time > when the stage-1 table is not protected. Which is
> > > > > by the way what I > would expect to see in most cases.
> > > > >
> > > > > I agree with Tamas: I also believe that in most cases the stage-1
> > > > > translation table won't be protected. So, in my opinion, falling back to
> > > > > software (which will be presumablly a rare operation) is the better
> > > > > approach.
> > > >
> > > >
> > > > Well, you both consider that it is better to do the fallback by assuming
> > > > the
> > > > TLBs will always cache the intermediate translations (e.g VA -> IPA) and
> > > > not
> > > > only the full S1 -> S2 translation (e.g VA -> PA).
> > >
> > > No, I was just pointing out that if the TLB has it cached it is
> > > guaranteed to be faster. Whether that is the case is probably usecase
> > > dependent. But even if the TLB is not loaded, I would assume the
> > > hardware lookup is at least as fast as the software based one, but I
> > > would bet it is faster. Without number this is just theoretical but I
> > > would be very surprised if the hardware lookup would ever be slower
> > > then the software based one... And since this is a corner-case that
> > > most application will never encounter, forcing them all to use a
> > > slower approach doesn't sound right.
> >
> > What you miss in my point is TLB can be designed to never cache intermediate
> > translation. It is not even about whether the TLB are loaded or not.
> >
> > I am struggling to understand why this would be a corner case as it would be
> > valid to protect the page table to inspect what the guest is doing...
> It is valid, yes, but nothing requires the user to block read access
> to that specific page. Most applications only monitor a handful of
> pages at a time. Applications may not even use read-access
> restrictions at all (doing only write or execute tracing). If we do
> software based lookups all the time we penalize all of those
> applications when it is really only a very small subset of cases where
> this will be needed.
>
> > I am not saying translation would be slower in hardware than in software. I
> > am just saying that maybe it would not be a huge performance hit to always
> > do software rather than fallback and having a worse one time to time (or
> > often?).
> It probably wouldn't be a big hit, but why take any hit if not necessary?
You still miss my point... Anyway, it is nothing something I really care 
for now. So I am not going to argue.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel