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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
> Hello Tamas,
>
> On 01/08/2016 21:41, Tamas K Lengyel wrote:
>>
>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>>>>
>>>> we did discuss whether altp2m on ARM should be exposed to guests or
>>>> not but we did not agree whether restricting it on ARM is absolutely
>>>> necessary. Altp2m was designed even on the x86 to be accessible from
>>>> within the guest on all systems irrespective of actual hardware
>>>> support for it.  Thus, this design fits ARM as well where there is no
>>>> dedicated hardware support, from the altp2m perspective there is no
>>>> difference.
>>>
>>>
>>>
>>> Really? I looked at the design document [1] which is Intel focus. Similar
>>> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c).
>>
>>
>> That design cover letter mentions specifically "Both VMFUNC and #VE
>> are designed such that a VMM can emulate them on legacy CPUs". While
>> they certainly had only Intel hardware in-mind, the software route can
>> also be taken on ARM as well. As our primary use-case is purely
>> external use of altp2m we have not implemented the bits that enable
>> the injection of mem_access faults into the guest (equivalent of #VE).
>> Whether without that the altp2m switching from within the guest make
>> sense or not is beyond the scope of this series but as it could
>> technically be implemented in the future, I don't see a reason to
>> disable that possibility right away.
>
>
> 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.
>

Hi Julien,
as I said our use-case is purely external so I don't have an actual
use-case for anything being accessible from within the guest. However,
I could imagine the gfn remapping be used to protect kernel memory
areas against information disclosure by only switching to the
accessible mapping
when certain conditions are met. Also, I had been able to use
mem_access from domUs with the use of XSM so I believe it would be
possible for a domain to enable mem_access on itself that way and thus
not having to implement #VE exactly the way x86 does and still have
feature parity.

Tamas

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