>>> On 26.09.18 at 12:51, <[email protected]> wrote: >> -----Original Message----- >> From: Julien Grall [mailto:[email protected]] >> Sent: 26 September 2018 11:41 >> To: Jan Beulich <[email protected]>; Paul Durrant >> <[email protected]> >> Cc: Andrew Cooper <[email protected]>; Roger Pau Monne >> <[email protected]>; Stefano Stabellini <[email protected]>; xen- >> devel <[email protected]> >> 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, <[email protected]> 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.
Yes, that's what I too would have thought. If there ever was a resource which may only be mapped r/o, p2m_ram_ro should then be equally usable. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
