KVM/QEMU community call @ 26/05/2026 agenda items?

KVM/QEMU community call @ 26/05/2026 agenda items?

[Alex Bennée]

Hi,

The KVM/QEMU community call is at:

https://meet.jit.si/kvmcallmeeting
@
26/05/2026 14:00 UTC

Are there any agenda items for the sync-up?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: KVM/QEMU community call @ 26/05/2026 agenda items?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 3113 bytes --]

On 5/22/26 07:56, Alex Bennée wrote:
> 
> Hi,
> 
> The KVM/QEMU community call is at:
> 
> https://meet.jit.si/kvmcallmeeting
> @
> 26/05/2026 14:00 UTC
> 
> Are there any agenda items for the sync-up?

I have (at least) six.  Four are related to the vhost-user spec,
one is related to the current vhost-user implementation in QEMU,
and one is related to MSI-X interrupts in the virtio PCI transport.

I'm not sure if these are better discussed offline, but:

The first is whether vhost-user memory regions
are guaranteed to not overlap.  I sent a patch in
https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
to guarantee this is not the case.  However, this is technically a
breaking spec change.  The virtio vhost-user device I'm working on
requires this.

The second is when the backend needs to remove memory regions removed
by VHOST_USER_REM_MEM_REG.  This could matter for Xen grant mapping.
Does it need to happen before the backend replies?

The third is whether a vhost-user backend can assume that the frontend
will always provide an eventfd where the protocol calls for one,
instead of falling back to pipe2() or pipe().  The virtio-vhost-user
device I am working on acts as a vhost-user backend and does not
support this.

The fourth is whether a virtio-PCI device specification can assume
that there are a large number of MSI-X interrupts available.
My understanding is that a vhost-user device can have up to 256
virtqueues.  If so, the version of the virtio-vhost user device
I am currently working on will require a device to offer 263 MSI-X
interrupts.

This is a workaround for a limitation of Cloud Hypervisor: it can't
handle changing irqfd to MSI-X mappings once the device has started.
This is already a bug, but I didn't want to add yet another feature
that Cloud Hypervisor didn't implement properly.

The fifth is the importance of the features I'm planning on leaving
out at first:

1. VHOST_USER_PROTOCOL_F_PAGEFAULT
2. VHOST_USER_PROTOCOL_F_HOST_NOTIFIER

VHOST_USER_PROTOCOL_F_PAGEFAULT is needed for post-copy live migration.
However, it requires the backend to provide the frontend with a
userfaultfd, which it could use to stall backend memory accesses
indefinitely.  This is an easy frontend to backend denial of service.
Furthermore, unless async page faults are supported, it is an
easy backend *kernel* denial of service.

VHOST_USER_PROTOCOL_F_HOST_NOTIFIER requires the driver to somehow
tell the frontend what memory to use.  Furthermore, I'm not sure if
it can prevent the frontend from mapping too much of it.

The sixth is if references to "QEMU" should be replaced by a more
generic term.  QEMU is not the only vhost-user implementation nowadays,
and there may be implementations that support features QEMU does not.
In fact, I believe that this is going to happen in the near term,
for vhost-user-GPU blob object support.  Alyssa Ross has implemented
this in Cloud Hypervisor, but I don't think QEMU supports it.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: KVM/QEMU community call @ 26/05/2026 agenda items?

[Manos Pitsidianakis]

On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
<demiobenour@gmail.com> wrote:
>
> On 5/22/26 07:56, Alex Bennée wrote:
> >
> > Hi,
> >
> > The KVM/QEMU community call is at:
> >
> > https://meet.jit.si/kvmcallmeeting
> > @
> > 26/05/2026 14:00 UTC
> >
> > Are there any agenda items for the sync-up?
>
> I have (at least) six.  Four are related to the vhost-user spec,
> one is related to the current vhost-user implementation in QEMU,
> and one is related to MSI-X interrupts in the virtio PCI transport.
>
> I'm not sure if these are better discussed offline, but:

IMHO these are all mailing list topics, vhost-user maintainers might
not be in the community call anyway.

I suggest sending patches (like you've already done) whenever it makes
sense, and please try not to flood the zone.

>
> The first is whether vhost-user memory regions
> are guaranteed to not overlap.  I sent a patch in
> https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
> to guarantee this is not the case.  However, this is technically a
> breaking spec change.  The virtio vhost-user device I'm working on
> requires this.
>
> The second is when the backend needs to remove memory regions removed
> by VHOST_USER_REM_MEM_REG.  This could matter for Xen grant mapping.
> Does it need to happen before the backend replies?
>
> The third is whether a vhost-user backend can assume that the frontend
> will always provide an eventfd where the protocol calls for one,
> instead of falling back to pipe2() or pipe().  The virtio-vhost-user
> device I am working on acts as a vhost-user backend and does not
> support this.
>
> The fourth is whether a virtio-PCI device specification can assume
> that there are a large number of MSI-X interrupts available.
> My understanding is that a vhost-user device can have up to 256
> virtqueues.  If so, the version of the virtio-vhost user device
> I am currently working on will require a device to offer 263 MSI-X
> interrupts.
>
> This is a workaround for a limitation of Cloud Hypervisor: it can't
> handle changing irqfd to MSI-X mappings once the device has started.
> This is already a bug, but I didn't want to add yet another feature
> that Cloud Hypervisor didn't implement properly.
>
> The fifth is the importance of the features I'm planning on leaving
> out at first:
>
> 1. VHOST_USER_PROTOCOL_F_PAGEFAULT
> 2. VHOST_USER_PROTOCOL_F_HOST_NOTIFIER
>
> VHOST_USER_PROTOCOL_F_PAGEFAULT is needed for post-copy live migration.
> However, it requires the backend to provide the frontend with a
> userfaultfd, which it could use to stall backend memory accesses
> indefinitely.  This is an easy frontend to backend denial of service.
> Furthermore, unless async page faults are supported, it is an
> easy backend *kernel* denial of service.
>
> VHOST_USER_PROTOCOL_F_HOST_NOTIFIER requires the driver to somehow
> tell the frontend what memory to use.  Furthermore, I'm not sure if
> it can prevent the frontend from mapping too much of it.
>
> The sixth is if references to "QEMU" should be replaced by a more
> generic term.  QEMU is not the only vhost-user implementation nowadays,
> and there may be implementations that support features QEMU does not.
> In fact, I believe that this is going to happen in the near term,
> for vhost-user-GPU blob object support.  Alyssa Ross has implemented
> this in Cloud Hypervisor, but I don't think QEMU supports it.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)

Re: KVM/QEMU community call @ 26/05/2026 agenda items?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 998 bytes --]

On 5/25/26 03:46, Manos Pitsidianakis wrote:
> On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
> <demiobenour@gmail.com> wrote:
>>
>> On 5/22/26 07:56, Alex Bennée wrote:
>>>
>>> Hi,
>>>
>>> The KVM/QEMU community call is at:
>>>
>>> https://meet.jit.si/kvmcallmeeting
>>> @
>>> 26/05/2026 14:00 UTC
>>>
>>> Are there any agenda items for the sync-up?
>>
>> I have (at least) six.  Four are related to the vhost-user spec,
>> one is related to the current vhost-user implementation in QEMU,
>> and one is related to MSI-X interrupts in the virtio PCI transport.
>>
>> I'm not sure if these are better discussed offline, but:
> 
> IMHO these are all mailing list topics, vhost-user maintainers might
> not be in the community call anyway.
> 
> I suggest sending patches (like you've already done) whenever it makes
> sense, and please try not to flood the zone.

Thanks for the (not too unexpected) clarification.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: KVM/QEMU community call @ 26/05/2026 agenda items?

[Alex Bennée]

Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:

> On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
> <demiobenour@gmail.com> wrote:
>>
>> On 5/22/26 07:56, Alex Bennée wrote:
>> >
>> > Hi,
>> >
>> > The KVM/QEMU community call is at:
>> >
>> > https://meet.jit.si/kvmcallmeeting
>> > @
>> > 26/05/2026 14:00 UTC
>> >
>> > Are there any agenda items for the sync-up?
>>
>> I have (at least) six.  Four are related to the vhost-user spec,
>> one is related to the current vhost-user implementation in QEMU,
>> and one is related to MSI-X interrupts in the virtio PCI transport.
>>
>> I'm not sure if these are better discussed offline, but:
>
> IMHO these are all mailing list topics, vhost-user maintainers might
> not be in the community call anyway.

It might be worth having the wider discussion about if the QEMU repo is
the place for the vhost-user spec. I know the rust-vmm people have a
regular call but I guess there isn't a venue for vhost-user discussions
that is not just on list.

> I suggest sending patches (like you've already done) whenever it makes
> sense, and please try not to flood the zone.
>
>>
>> The first is whether vhost-user memory regions
>> are guaranteed to not overlap.  I sent a patch in
>> https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
>> to guarantee this is not the case.  However, this is technically a
>> breaking spec change.  The virtio vhost-user device I'm working on
>> requires this.

Breaking spec changes are always a red flag because of whats already
deployed. Are you sure there is no way to make changes optional with use
of feature flags?

>>
>> The second is when the backend needs to remove memory regions removed
>> by VHOST_USER_REM_MEM_REG.  This could matter for Xen grant mapping.
>> Does it need to happen before the backend replies?
>>
>> The third is whether a vhost-user backend can assume that the frontend
>> will always provide an eventfd where the protocol calls for one,
>> instead of falling back to pipe2() or pipe().  The virtio-vhost-user
>> device I am working on acts as a vhost-user backend and does not
>> support this.
>>
>> The fourth is whether a virtio-PCI device specification can assume
>> that there are a large number of MSI-X interrupts available.
>> My understanding is that a vhost-user device can have up to 256
>> virtqueues.  If so, the version of the virtio-vhost user device
>> I am currently working on will require a device to offer 263 MSI-X
>> interrupts.
>>
>> This is a workaround for a limitation of Cloud Hypervisor: it can't
>> handle changing irqfd to MSI-X mappings once the device has started.
>> This is already a bug, but I didn't want to add yet another feature
>> that Cloud Hypervisor didn't implement properly.
>>
>> The fifth is the importance of the features I'm planning on leaving
>> out at first:
>>
>> 1. VHOST_USER_PROTOCOL_F_PAGEFAULT
>> 2. VHOST_USER_PROTOCOL_F_HOST_NOTIFIER
>>
>> VHOST_USER_PROTOCOL_F_PAGEFAULT is needed for post-copy live migration.
>> However, it requires the backend to provide the frontend with a
>> userfaultfd, which it could use to stall backend memory accesses
>> indefinitely.  This is an easy frontend to backend denial of service.
>> Furthermore, unless async page faults are supported, it is an
>> easy backend *kernel* denial of service.
>>
>> VHOST_USER_PROTOCOL_F_HOST_NOTIFIER requires the driver to somehow
>> tell the frontend what memory to use.  Furthermore, I'm not sure if
>> it can prevent the frontend from mapping too much of it.
>>
>> The sixth is if references to "QEMU" should be replaced by a more
>> generic term.  QEMU is not the only vhost-user implementation nowadays,
>> and there may be implementations that support features QEMU does not.
>> In fact, I believe that this is going to happen in the near term,
>> for vhost-user-GPU blob object support.  Alyssa Ross has implemented
>> this in Cloud Hypervisor, but I don't think QEMU supports it.
>> --
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: KVM/QEMU community call @ 26/05/2026 agenda items?

[Alex Bennée]

Alex Bennée <alex.bennee@linaro.org> writes:

> Hi,
>
> The KVM/QEMU community call is at:
>
> https://meet.jit.si/kvmcallmeeting
> @
> 26/05/2026 14:00 UTC
>
> Are there any agenda items for the sync-up?

Given there is some discussion on the list w.r.t. AI contributions would
it be worth discussing the topic today?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

vhost-user(?) breaking changes

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

[Trimming CC substantially.]

Alex Bennée <alex.bennee@linaro.org> writes:

> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>
>> On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
>> <demiobenour@gmail.com> wrote:
>>>
>>> The first is whether vhost-user memory regions
>>> are guaranteed to not overlap.  I sent a patch in
>>> https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
>>> to guarantee this is not the case.  However, this is technically a
>>> breaking spec change.  The virtio vhost-user device I'm working on
>>> requires this.
>
> Breaking spec changes are always a red flag because of whats already
> deployed. Are you sure there is no way to make changes optional with use
> of feature flags?

There's some nuance between breaking changes and clarifications though,
right?  e.g. 97f24a0496 ("vhost-user.rst: clarify when FDs can be sent")
tightened things up, so could also have been in principle have been seen
as a breaking change, but not practically.

Are there likely to be devices that use overlapping memory regions
today?  Would we expect that to work?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: vhost-user(?) breaking changes

[Alex Bennée]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Alyssa Ross <hi@alyssa.is> writes:

> [Trimming CC substantially.]
>
> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>>
>>> On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
>>> <demiobenour@gmail.com> wrote:
>>>>
>>>> The first is whether vhost-user memory regions
>>>> are guaranteed to not overlap.  I sent a patch in
>>>> https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
>>>> to guarantee this is not the case.  However, this is technically a
>>>> breaking spec change.  The virtio vhost-user device I'm working on
>>>> requires this.
>>
>> Breaking spec changes are always a red flag because of whats already
>> deployed. Are you sure there is no way to make changes optional with use
>> of feature flags?
>
> There's some nuance between breaking changes and clarifications though,
> right?  e.g. 97f24a0496 ("vhost-user.rst: clarify when FDs can be sent")
> tightened things up, so could also have been in principle have been seen
> as a breaking change, but not practically.

Sure - if in practice we are encoding an assumption that wasn't explicit
but everyone* was making anyway I think that fair.

> Are there likely to be devices that use overlapping memory regions
> today?  Would we expect that to work?

I personally don't know - and I didn't feel qualified to opine either
way. This opens up the wider question of who would know and are they
following discussions about this on qemu-devel?

For that see the other thread I've just started where you and a bunch of
others are CC'd ;-)

*everyone - do we have a comprehensive list of who implements vhost-user
 these days?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 519 bytes --]

vhost-user implementations

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

Alex Bennée <alex.bennee@linaro.org> writes:

> *everyone - do we have a comprehensive list of who implements vhost-user
>  these days?

I'll get started with some implementations I know about :)

Frontends
---------

• crosvm
• QEMU
• Cloud Hypervisor
• Firecracker
• StratoVirt
• alioth
• Dragonball

Backends
--------

• vhost-device
• virtiofsd
• crosvm
• Cloud Hypervisor
• Spectrum's router
• DPDK
• SPDK

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: vhost-user implementations

[Felipe Franciosi]

> On 27 May 2026, at 10:52, Alyssa Ross <hi@alyssa.is> wrote:
> 
> Alex Bennée <alex.bennee@linaro.org> writes:
> 
>> *everyone - do we have a comprehensive list of who implements vhost-user
>> these days?
> 
> I'll get started with some implementations I know about :)
> 
> Frontends
> ---------
> 
> • crosvm
> • QEMU
> • Cloud Hypervisor
> • Firecracker
> • StratoVirt
> • alioth
> • Dragonball
> 
> Backends
> --------
> 
> • vhost-device
> • virtiofsd
> • crosvm
> • Cloud Hypervisor
> • Spectrum's router
> • DPDK
> • SPDK

Nutanix AHV leverages vhost-user-scsi. Apologies but I missed the original
message somehow. Do you need our help to port or validate changes?

Cheers!
F.

Re: vhost-user implementations

[Stefan Hajnoczi]

On Wed, May 27, 2026 at 5:52 AM Alyssa Ross <hi@alyssa.is> wrote:
> Backends
> --------
>
> • vhost-device
> • virtiofsd
> • crosvm
> • Cloud Hypervisor
> • Spectrum's router
> • DPDK
> • SPDK

- QEMU's libvhost-user

Re: vhost-user(?) breaking changes

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1991 bytes --]

On 5/27/26 04:20, Alyssa Ross wrote:
> [Trimming CC substantially.]
> 
> Alex Bennée <alex.bennee@linaro.org> writes:
> 
>> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>>
>>> On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
>>> <demiobenour@gmail.com> wrote:
>>>>
>>>> The first is whether vhost-user memory regions
>>>> are guaranteed to not overlap.  I sent a patch in
>>>> https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
>>>> to guarantee this is not the case.  However, this is technically a
>>>> breaking spec change.  The virtio vhost-user device I'm working on
>>>> requires this.
>>
>> Breaking spec changes are always a red flag because of whats already
>> deployed. Are you sure there is no way to make changes optional with use
>> of feature flags?
> 
> There's some nuance between breaking changes and clarifications though,
> right?  e.g. 97f24a0496 ("vhost-user.rst: clarify when FDs can be sent")
> tightened things up, so could also have been in principle have been seen
> as a breaking change, but not practically.
> 
> Are there likely to be devices that use overlapping memory regions
> today?  Would we expect that to work?

If an address matches more than one region, the current specification
doesn't state which one should be chosen.  I suspect current backends
either pick one arbitrarily or fail.  I don't think either behavior
is particularly useful.

If the frontend never sends an address that matches more than one
region, I expect things will work fine.  However, this means that the
overlapping part cannot be used safely.  I don't think that this is
a useful thing for a frontend to do.

Treating overlapping regions as an error has the advantage of being
testable and well-defined.  Also, this only means that frontends
must not send overlapping regions.  It doesn't require backends to
change behavior.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]