Re: [PATCH v6 0/3] Support multiple ioreq pages

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.09.2026 10:09, Anthony PERARD wrote:
> On Tue, Aug 18, 2026 at 04:08:04PM +0200, Jan Beulich wrote:
>> On 20.04.2026 11:38, Julian Vetter wrote:
>>> Julian Vetter (3):
>>>   ioreq: switch ioreq page allocation to vmap
>>>   ioreq: Indent ioreq_server_alloc_mfn() body one level deeper
>>>   x86/ioreq: Extend ioreq server to support multiple ioreq pages
>>>
>>>  xen/arch/x86/hvm/ioreq.c |  63 ++++++++++++++++---
>>>  xen/common/ioreq.c       | 127 ++++++++++++++++++++++++++-------------
>>>  xen/include/xen/ioreq.h  |  13 +++-
>>>  3 files changed, 151 insertions(+), 52 deletions(-)
>>
>> For (future) reference, in case it wasn't said earlier:
>>
>> To be able to test this, at least the last patch here will want to wait
>> until the apic_id == vcpu_id * 2 issue was addressed. Andrew said he'd pick
>> up Alejandro's work there, thus - once finished - permitting up to 255
>> vCPU-s (i.e. requiring 2 IOREQ pages).
>>
>> Once (really: before) we grow the number of vCPU-s for HVM, we need to
>> revisit the amount of VA space set aside for vmap(). For many years we've
>> been adding new uses of vmap() without making sure its reserved range is
>> still adequately sized.
>>
>> Since multi-page functionality added here will also need qemu changes, and
>> since we did determine (elsewhere) that ioreq_t needs to grow as well, it
>> remains to be decided whether the two changes wouldn't better be done
>> together, to keep the qemu backwards compatibility logic somewhat limited
>> in size / complexity. Anthony (in particular) - thoughts?
> 
> Put like that, how can I say "no" to merge both changes together :-)
> 
> It will certainly be simpler to maintain if having one feature mean also
> having the other. But it kind of depends on whether both changes are
> ready to go in at around the same time. I don't really know how the
> changes in QEMU will look like, and how QEMU will choose or have a
> choice of which feature to use, and it might be one that can be
> negotiated as runtime and the other one been a compile time change (as I
> think QEMU still depends on unstable ABI).
> 
> But it looks like both changes in QEMU are for having more vCPU, so
> having both at the same time might be better.

Growing ioreq_t (in particular the data size it can hold) doesn't have
anything to do with increased vCPU count, I think.

> So yes, I'm all for less complexity, but I can't ask for this to be a
> blocker, especially if the other change might takes years. So far, I
> don't think I've seen any patches for QEMU.

How exactly a new ioreq_t would want to look like remains to be discussed.
Perhaps we could go an intermediate route here: Add provisions (e.g. a
full page per vCPU, plus a format identifier at the start of that page),
allowing the enlarged ioreq_t to be put on top, yet without needing any
(further) changes to the map/unmap logic?

Jan