[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.
On 02/08/16 08:38, Julien Grall wrote: > 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. It seems like having guest altp2m support without the equivalent of a #VE does seem pretty useless. Would you disagree with this assessment, Tamas? Every interface we expose to the guest increases the surface of attack; so it seems like until there is a usecase for guest altp2m, we should probably disable it. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |