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

[Julien Grall <julien.grall@xxxxxxx>]

On 03/08/16 13:00, Andrew Cooper wrote:
> On 03/08/16 12:53, Julien Grall wrote:
> > 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.
> #VE is a newly specified CPU exception, precisely for reporting state 2
> violations (in ARM terminology).  It works very much like a pagefault.
Thank you for the explanation. We don't have any specific exception to 
report stage 2 (I guess EPT for x86 terminology) violations.
If the guest physical address does not belong to an emulated device or 
does not have an associated host address, the hypervisor will inject a 
data/prefetch abort to the guest.
Those aborts contains a fault status. For now it is always the same 
fault: debug fault on AArch32 and address size fault on AArch64. I don't 
think we can re-use one of the fault (see ARM D7-1949 in DDI 0487A.j for 
the list of fault code) to behave as #VE.
I guess the best would be an event channel for this purpose.

> ~Andrew
--
Julien Grall

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