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

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current



Hi Andrew,

On 13/12/16 19:39, Andrew Cooper wrote:
On 13/12/16 18:41, Julien Grall wrote:
On 13/12/16 18:28, Andrew Cooper wrote:
On 12/12/16 23:47, Tamas K Lengyel wrote:
Newer versions of VT-x/SVM may provide additional information on a
vmexit, which include a guest physical address relevant to the the
reason for the vmexit.

Xen will attempt to proactively use this information to avoid a software
pagewalk, but can always fall back to the software method if needs be.

That is a good idea, but may bring some issue with memacces as we
currently have on ARM.

Why would a software-only approach have problem on ARM?  Slow certainly,
but it should function correctly.

Sorry I meant, that using hardware instruction to translate an address on ARM has some drawback when using memaccess.

However, ARM supports 2 kind of page tables (short page table and LPAE), different page size (4KB, 16KB, 64KB), split page tables, endianness... This would require some works to make all the combinations working.

Furthermore, on 32-bit host not all the RAM is mapped in Xen. So guest pages are mapped on demand, requiring TLB invalidation.

So I would only use the software approach when it is strictly necessary.





I presume ARM has always relied on hardware support for translation, and
has no software translation support?  I presume therefore that
translations only work when in current context?

That's correct. ARM provided hardware support for most of translation
from the start. But it relies on the guest page table to be accessible
(e.g there is no memory restriction in stage-2).

Ok, so ARM provides an instruction to translate an arbitrary virtual
address to guest physical.  How does this work in the context of Xen, or
can hardware follow the currently-active virtualisation state to find
the guest pagetables?  Or does it rely on information in the TLB?

Xen and the guest vCPU are using different separate set of the registers. When running in Xen context, the guest vCPU state is still present and will be used by the hardware to translate a VA to guest physical address.


Note that ARM does not provide any hardware instruction to translate
an IPA (guest physical address) to a PA. So we have a walker there.

We also a walk for debugging guest page table (though only when it is
using LPAE). I guess it could be re-used in the case where it is not
possible to do it in hardware. Although, it would be rewritten to make
it safe.

This sounds like the kind of thing which would be generally useful,
although I'd like to understand the problem better before making
suggestions.

memaccess will restrict permission of certain memory regions in stage-2 page table. For the purpose of the example, lets say read-access as been restricted.

One of these memory regions may contain the stage-1 page table. Do you agree that the guest will not able to read stage-1 page table due the restriction?

Similarly, when the hardware will do the page table walk it all the accesses will be on behalf of the guest. So a read on stage-1 page table would fail and the hardware will not be able to do the translation.

I hope this clarify the problem.

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