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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Andrew,

On 02/08/2016 00:14, Andrew Cooper wrote:
> On 01/08/2016 19:15, Julien Grall wrote:
> > On 01/08/16 18:10, Sergej Proskurin wrote:
> > > Hello all,
> > Hello Sergej,
> >
> > > The following patch series can be found on Github[0] and is part of my
> > > contribution to this year's Google Summer of Code (GSoC)[1]. My
> > > project is
> > > managed by the organization The Honeynet Project. As part of GSoC, I
> > > am being
> > > supervised by the Xen developer Tamas K. Lengyel
> > > <tamas@xxxxxxxxxxxxx>, George
> > > D. Webster, and Steven Maresca.
> > >
> > > In this patch series, we provide an implementation of the altp2m
> > > subsystem for
> > > ARM. Our implementation is based on the altp2m subsystem for x86,
> > > providing
> > > additional --alternate-- views on the guest's physical memory by
> > > means of the
> > > ARM 2nd stage translation mechanism. The patches introduce new HVMOPs
> > > and
> > > extend the p2m subsystem. Also, we extend libxl to support altp2m on
> > > ARM and
> > > modify xen-access to test the suggested functionality.
> > >
> > > To be more precise, altp2m allows to create and switch to additional
> > > p2m views
> > > (i.e. gfn to mfn mappings). These views can be manipulated and
> > > activated as
> > > will through the provided HVMOPs. In this way, the active guest
> > > instance in
> > > question can seamlessly proceed execution without noticing that
> > > anything has
> > > changed. The prime scope of application of altp2m is Virtual Machine
> > > Introspection, where guest systems are analyzed from the outside of
> > > the VM.
> > >
> > > Altp2m can be activated by means of the guest control parameter
> > > "altp2m" on x86
> > > and ARM architectures.  The altp2m functionality by default can also
> > > be used
> > > from within the guest by design. For use-cases requiring purely
> > > external access
> > > to altp2m, a custom XSM policy is necessary on both x86 and ARM.
> > As said on the previous version, altp2m operation *should not* be
> > exposed to ARM guest. Any design written for x86 may not fit exactly
> > for ARM (and vice versa), you will need to explain why you think we
> > should follow the same pattern.
> Sorry, but I am going to step in here and disagree.  All the x86
> justifications for altp2m being accessible to guests apply equally to
> ARM, as they are hardware independent.
>
> I realise you are maintainer, but the onus is on you to justify why the
> behaviour should be different between x86 and ARM, rather than simply to
> complain at it being the same.
>
> Naturally, technical issues about the details of the implementation, or
> the algorithms etc. are of course fine, but I don't see any plausible
> reason why ARM should purposefully different from x86 in terms of
> available functionality, and several good reasons why it should be the
> same (least of all, feature parity across architectures).
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,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel