Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Mon, Aug 1, 2016 at 4:33 AM, Julien Grall <julien.grall@xxxxxxx> wrote:
> Hello Tamas,
>
> On 29/07/16 23:26, Tamas K Lengyel wrote:
>>
>> However, as this patch really only touches
>> things that belong to mem_access/monitor components maybe we should
>> split these from the generic ARM code altogether to avoid such
>> conflicts in the future.
>
>
> I am not against moving part of mem_access outside of the P2M. However, the
> ARM (32-bit and 64-bit) code needs a lot more attention to make it work in
> *all* the case. I was able to break memaccess quite easily on various
> platform (include models).

Yeap, we were able to reproduce the issue on our XU as well. It
fortunately only occurs in a somewhat less-used part of mem_access
where the user changes the default_access and also doesn't pause the
domain while setting mem_access. If either of those conditions aren't
true the bug is avoided. I'm not aware of anyone actually using
default_access at this point, it is a legacy option present in
mem_access for a now unknown use-case.

>
> For instance p2m_mem_access_check_and_get_page is using the hardware to
> translate a VA to an IPA. This only works if the memory where the stage-1
> page tables reside is not protected. The upcoming support of altp2m will
> make things trickier.
>
> The interface of p2m_mem_access_check_and_get_page should also be updated to
> take a VCPU in parameter.

Agree.

>
> Lastly getting/setting access in the the mem_access_settings radix tree
> should stay in the p2m code as it is tight to stage-2 page table
> implementation.

Keeping the radix bookkeeping in p2m should be fine from our
perspective. We will need the p2m lock functions accessible though
from outside p2m (as well as the p2m_{set/get}_entry functions).

Thanks,
Tamas

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