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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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