Re: [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

[Chao Gao <chao.gao@intel.com>]

On Wed, Dec 06, 2017 at 03:04:11PM +0000, Paul Durrant wrote:
>> -----Original Message-----
>> From: Chao Gao [mailto:chao.gao@intel.com]
>> Sent: 06 December 2017 07:50
>> To: xen-devel@lists.xen.org
>> Cc: Chao Gao <chao.gao@intel.com>; Paul Durrant
>> <Paul.Durrant@citrix.com>; Tim (Xen.org) <tim@xen.org>; Stefano Stabellini
>> <sstabellini@kernel.org>; Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com>; Jan Beulich <jbeulich@suse.com>; George
>> Dunlap <George.Dunlap@citrix.com>; Andrew Cooper
>> <Andrew.Cooper3@citrix.com>; Wei Liu <wei.liu2@citrix.com>; Ian Jackson
>> <Ian.Jackson@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.

Thanks
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel