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 19:55, Julien Grall wrote:
> 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
* it is not something

> 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