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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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.

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.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech