Re: [PATCH v3 2/2] x86/ioreq: Extend ioreq server to support multiple ioreq pages

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.03.2026 17:48, Julian Vetter wrote:
> On 2/26/26 16:54, Jan Beulich wrote:
>> On 23.02.2026 10:38, Julian Vetter wrote:
>>> A single shared ioreq page provides PAGE_SIZE/sizeof(ioreq_t) = 128
>>> slots, limiting HVM guests to 128 vCPUs. To support more vCPUs, extend
>>> the ioreq server to use xvzalloc_array() for allocating a contiguous
>>> virtual array of ioreq_t slots sized to d->max_vcpus, backed by
>>> potentially non-contiguous physical pages.
>>>
>>> For the GFN-mapped path (x86), page and writable type references are
>>> obtained directly via check_get_page_from_gfn() and get_page_type() for
>>> each GFN. The pages are then combined into a single contiguous VA using
>>> vmap(). The number of ioreq pages is computed at runtime via
>>> nr_ioreq_pages(d) = DIV_ROUND_UP(d->max_vcpus, IOREQS_PER_PAGE), so
>>> small VMs only allocate one page. All existing single-page paths
>>> (bufioreq, legacy clients) remain unchanged.
>>>
>>> Mark the now-unused shared_iopage_t in the public header as deprecated.
>>
>> For this I think we need to settle on one of two options: Either it was a
>> mistake that this was used in the hypervisor (and added to the public
>> interface), in which case the removal of the use may want to be separate
>> (without, imo, any need to mark the item deprecated in the public header,
>> as the property remains). Or we deem it legitimate / useful, in which case
>> you would want to continue using it (in struct ioreq_server).
> 
> Thank you Jan for you feedback! It's very appreciated! You're right. But 
> I'm wondering how would dropping the struct work? I looked into QEMU and 
> varstored, and they both use this struct at the moment. But 
> modifications to both of them would be minimal if we decide to drop the 
> struct. And if they want to support multiple ioreq pages we would need 
> to modify this struct anyway to not contain a single struct ioreq, but a 
> pointer or [].

There may be a misunderstanding here: I said "drop the use" (in the hypervisor,
that is), not "drop the struct". There's also no strong need for a pointer or
[], as it looks: It being [1] right now is, aiui, a poor man's flexible array.
For one, for general use the public headers need to be C89 compatible, i.e. no
flexibly arrays unconditionally. While we do have some conditional uses (see
XEN_FLEX_ARRAY_DIM), that may not be usable here, as the array is the sole
field of the struct.

Jan