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

[Jan Beulich <jbeulich@suse.com>]

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?

There may be more aspects which I forget.

Jan