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

[Julien Grall <julien.grall@xxxxxxx>]

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