> -----Original Message----- > From: Chao Gao [mailto:[email protected]] > Sent: 06 December 2017 09:02 > To: Paul Durrant <[email protected]> > Cc: [email protected]; Tim (Xen.org) <[email protected]>; Stefano > Stabellini <[email protected]>; Konrad Rzeszutek Wilk > <[email protected]>; Jan Beulich <[email protected]>; George > Dunlap <[email protected]>; Andrew Cooper > <[email protected]>; Wei Liu <[email protected]>; Ian Jackson > <[email protected]> > 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:[email protected]] > >> Sent: 06 December 2017 07:50 > >> To: [email protected] > >> Cc: Chao Gao <[email protected]>; Paul Durrant > >> <[email protected]>; Tim (Xen.org) <[email protected]>; Stefano > Stabellini > >> <[email protected]>; Konrad Rzeszutek Wilk > >> <[email protected]>; Jan Beulich <[email protected]>; George > >> Dunlap <[email protected]>; Andrew Cooper > >> <[email protected]>; Wei Liu <[email protected]>; Ian > Jackson > >> <[email protected]> > >> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
