> -----Original Message----- > From: Chao Gao [mailto:chao....@intel.com] > Sent: 06 December 2017 09:02 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: xen-de...@lists.xen.org; Tim (Xen.org) <t...@xen.org>; Stefano > Stabellini <sstabell...@kernel.org>; Konrad Rzeszutek Wilk > <konrad.w...@oracle.com>; Jan Beulich <jbeul...@suse.com>; George > Dunlap <george.dun...@citrix.com>; Andrew Cooper > <andrew.coop...@citrix.com>; Wei Liu <wei.l...@citrix.com>; Ian Jackson > <ian.jack...@citrix.com> > Subject: Re: [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 > pages > > On Wed, Dec 06, 2017 at 03:04:11PM +0000, Paul Durrant wrote: > >> -----Original Message----- > >> From: Chao Gao [mailto:chao....@intel.com] > >> Sent: 06 December 2017 07:50 > >> To: xen-de...@lists.xen.org > >> Cc: Chao Gao <chao....@intel.com>; Paul Durrant > >> <paul.durr...@citrix.com>; Tim (Xen.org) <t...@xen.org>; Stefano > Stabellini > >> <sstabell...@kernel.org>; Konrad Rzeszutek Wilk > >> <konrad.w...@oracle.com>; Jan Beulich <jbeul...@suse.com>; George > >> Dunlap <george.dun...@citrix.com>; Andrew Cooper > >> <andrew.coop...@citrix.com>; Wei Liu <wei.l...@citrix.com>; Ian > Jackson > >> <ian.jack...@citrix.com> > >> Subject: [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 > >> pages > >> > >> One 4K-byte page at most contains 128 'ioreq_t'. In order to remove the > vcpu > >> number constraint imposed by one IOREQ page, bump the number of > IOREQ > >> page to > >> 4 pages. With this patch, multiple pages can be used as IOREQ page. > >> > >> Basically, this patch extends 'ioreq' field in struct hvm_ioreq_server to > >> an > >> array. All accesses to 'ioreq' field such as 's->ioreq' are replaced with > >> FOR_EACH_IOREQ_PAGE macro. > >> > >> In order to access an IOREQ page, QEMU should get the gmfn and map > this > >> gmfn > >> to its virtual address space. > > > >No. There's no need to extend the 'legacy' mechanism of using magic page > gfns. You should only handle the case where the mfns are allocated on > demand (see the call to hvm_ioreq_server_alloc_pages() in > hvm_get_ioreq_server_frame()). The number of guest vcpus is known at > this point so the correct number of pages can be allocated. If the creator of > the ioreq server attempts to use the legacy hvm_get_ioreq_server_info() > and the guest has >128 vcpus then the call should fail. > > Great suggestion. I will introduce a new dmop, a variant of > hvm_get_ioreq_server_frame() for creator to get an array of gfns and the > size of array. And the legacy interface will report an error if more > than one IOREQ PAGES are needed.
You don't need a new dmop for mapping I think. The mem op to map ioreq server frames should work. All you should need to do is update hvm_get_ioreq_server_frame() to deal with an index > 1, and provide some means for the ioreq server creator to convert the number of guest vcpus into the correct number of pages to map. (That might need a new dm op). Paul > > Thanks > Chao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel