> -----Original Message----- > From: Jan Beulich [mailto:[email protected]] > Sent: 14 December 2017 13:46 > To: Paul Durrant <[email protected]> > Cc: Julien Grall <[email protected]>; Andrew Cooper > <[email protected]>; George Dunlap > <[email protected]>; Ian Jackson <[email protected]>; Wei Liu > <[email protected]>; Stefano Stabellini <[email protected]>; xen- > [email protected]; Tim (Xen.org) <[email protected]> > Subject: Re: [PATCH v14 06/11] x86/hvm/ioreq: add a new mappable > resource type... > > >>> On 14.12.17 at 10:51, <[email protected]> wrote: > >> From: Paul Durrant [mailto:[email protected]] > >> Sent: 28 November 2017 15:09 > >> +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf) > >> +{ > >> + struct domain *currd = current->domain; > >> + struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; > >> + > >> + if ( iorp->page ) > >> + { > >> + /* > >> + * If a guest frame has already been mapped (which may happen > >> + * on demand if hvm_get_ioreq_server_info() is called), then > >> + * allocating a page is not permitted. > >> + */ > >> + if ( !gfn_eq(iorp->gfn, INVALID_GFN) ) > >> + return -EPERM; > >> + > >> + return 0; > >> + } > >> + > >> + /* > >> + * Allocated IOREQ server pages are assigned to the emulating > >> + * domain, not the target domain. This is because the emulator is > >> + * likely to be destroyed after the target domain has been torn > >> + * down, and we must use MEMF_no_refcount otherwise page > allocation > >> + * could fail if the emulating domain has already reached its > >> + * maximum allocation. > >> + */ > >> + iorp->page = alloc_domheap_page(currd, MEMF_no_refcount); > > > > This is no longer going to work as it is predicated on my original > > modification to HYPERVISOR_mmu_update (which allowed a PV domain to > map a > > foreign MFN from a domain over which it had privilege as if the MFN was > > local). Because that mechanism was decided against, this code needs to > change > > to use the target domain of the ioreq server rather than the calling domain. > > I will verfy this modification and submit v15 of the series. > > > > Jan, are you ok for me to keep your R-b? > > This is all pretty fragile - better drop it and I'll then take a look > once you've sent the new version.
Ok. Will do. Paul > > Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
