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

[Julien Grall <julien.grall@xxxxxxx>]

On 02/08/16 17:08, Andrew Cooper wrote:
> On 02/08/16 08:34, Julien Grall wrote:
> > 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.
> Does ARM have anything like #VE whereby an in-guest entity can receive
> notification of violations?
I am not entirely sure what is exactly the #VE. From my understanding, 
it use to report stage 2 violation to the guest, right? If so, I am not 
aware of any.
Regards,

--
Julien Grall

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