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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.



Hello Tamas,

On 01/08/2016 21:41, Tamas K Lengyel wrote:
On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
we did discuss whether altp2m on ARM should be exposed to guests or
not but we did not agree whether restricting it on ARM is absolutely
necessary. Altp2m was designed even on the x86 to be accessible from
within the guest on all systems irrespective of actual hardware
support for it.  Thus, this design fits ARM as well where there is no
dedicated hardware support, from the altp2m perspective there is no
difference.


Really? I looked at the design document [1] which is Intel focus. Similar
think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c).

That design cover letter mentions specifically "Both VMFUNC and #VE
are designed such that a VMM can emulate them on legacy CPUs". While
they certainly had only Intel hardware in-mind, the software route can
also be taken on ARM as well. As our primary use-case is purely
external use of altp2m we have not implemented the bits that enable
the injection of mem_access faults into the guest (equivalent of #VE).
Whether without that the altp2m switching from within the guest make
sense or not is beyond the scope of this series but as it could
technically be implemented in the future, I don't see a reason to
disable that possibility right away.

The question here, is how a guest could take advantage to access to altp2m on ARM today? Whilst on x86 a guest could be notified about memaccess change, this is not yet the case on ARM.

So, from my understanding, exposing this feature to a guest is like exposing a no-op with side effects. We should avoid to expose feature to the guest until there is a real usage and the guest could do something useful with it.

This has always been the case where some features were not fully ported on ARM until there is an actual usage (or we differ because there will be no-usage). The interface is already there, so a future Xen release can decide to give access to the guest when (and only when) this will be useful.

Regards,


Tamas


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