[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] IOREQ server on Arm



> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxx]
> Sent: 26 September 2018 11:33
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; 'Jan Beulich'
> <JBeulich@xxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Roger Pau Monne
> <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; xen-
> devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: IOREQ server on Arm
> 
> Hi,
> 
> On 09/26/2018 10:14 AM, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 26 September 2018 09:09
> >> To: Julien Grall <julien.grall@xxxxxxx>; Paul Durrant
> >> <Paul.Durrant@xxxxxxxxxx>
> >> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Roger Pau Monne
> >> <roger.pau@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
> xen-
> >> devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> >> Subject: Re: IOREQ server on Arm
> >>
> >>>>> On 26.09.18 at 00:39, <julien.grall@xxxxxxx> 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.
> >>
> >
> > Yes, that's correct. There is a FIXME clause in acquire_resource so that
> that only caller owned resources can be mapped by HVM/PVH domains. Thus
> the new call can be used for IOREQ server pages, but not grant frames.
> 
> I don't understand your last sentence. IOREQ is caller owned and
> therefore should work.

Yes, I was just saying that it is currently the only resource that should work.

> 
> As I said, I don't have any problem with mapping the resource. The
> problem is when unmapping it because the region is set with
> p2m_mapping_foreign. You will reach the ASSERT(fdom != p2m->domain) in
> p2m_get_page_from_gfn.
> 
> Regardless the reference problem (we support it on Arm). Can you explain
> how this is working on PVH Dom0 today?
> 

I never tested with a PVH dom0, but I did run tests with an HVM domU (and a Xen 
with the privilege checks hacked out). I guess I didn't re-test with HVM after 
the switch to caller-owned (which came quite late in review) and so missed this 
problem. Sorry about that.

  Paul

> Cheers,
> 
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.