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

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





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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.