Hi Paul,
On 09/26/2018 11:51 AM, Paul Durrant wrote:
-----Original Message-----
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 26 September 2018 11:41
To: Jan Beulich <jbeul...@suse.com>; Paul Durrant
<paul.durr...@citrix.com>
Cc: Andrew Cooper <andrew.coop...@citrix.com>; Roger Pau Monne
<roger....@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>; xen-
devel <xen-devel@lists.xenproject.org>
Subject: Re: IOREQ server on Arm
Hi Jan,
On 09/26/2018 09:08 AM, Jan Beulich wrote:_
On 26.09.18 at 00:39, <julien.gr...@arm.com> wrote:
Hi Paul,
I am looking at porting the IOREQ server infrastructure on Arm. I
didn't
need much modification to make it run for Arm. Although, the
implementation could be simplified over the x86 implementation.
I noticed some issue while trying to implement the hypercall
XENMEM_acquire_resource. Per my understanding, all the page mapped via
that hypercall will use the type p2m_mapping_foreign.
This will result to trigger the ASSERT(fdom != dom) in
get_page_from_gfn
(asm-arm/p2m.h) because the IOREQ page has been allocated to the
emulator domain and mapped to it. AFAICT x86 has the same assert in
p2m_get_page_from_gfn(...).
IHMO, the ASSERT makes sense because you are only meant to map page
belonging to other domain with that type.
So I am wondering whether IOREQ server running in PVH Dom0 has been
tested? What would be the best course of action to fix the issue?
I think the p2m type needs to be chosen based on
XENMEM_rsrc_acq_caller_owned.
I am thinking to introduce p2m_mapping_owned. Or do we have a p2m_type
that we could re-use?
I think we should be able to just use p2m_ram_rw if it is caller owned.
I thought about p2m_ram_rw but discarded because of the security
implications. At least on Arm, this type can be used for foreign
mapping, guest_copy helpers. This is not the case for p2m_mapping_foreign.
Do we want to allow thoses resources to be used in hypercall buffer
and/or mapped by other guest via the foreign API? If not, then we want
to use a different type.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
