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

[Julien Grall <julien.grall@arm.com>]

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@tklengyel.com>, 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@lists.xen.org
https://lists.xen.org/xen-devel