[PATCH] Mark Multi-Process QEMU as Orphaned

[PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

This subsystem is no longer seeing any development, and the primary
contact listed as maintainer has confirmed they're dropping support of
it altogether.

Signed-off-by: John Levon <john.levon@nutanix.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a90204ae9..ce2b494086 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
 Multi-process QEMU
 M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
 M: Jagannathan Raman <jag.raman@oracle.com>
-S: Maintained
+S: Orphan
 F: docs/devel/multi-process.rst
 F: docs/system/multi-process.rst
 F: hw/pci-host/remote.c
-- 
2.43.0

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Peter Maydell]

On Fri, 8 May 2026 at 11:27, John Levon <john.levon@nutanix.com> wrote:
>
> This subsystem is no longer seeing any development, and the primary
> contact listed as maintainer has confirmed they're dropping support of
> it altogether.
>
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

If there's no longer interest in it, can/should we list it as deprecated
in docs/about/deprecated.rst, so that we can remove it once the
deprecation period has passed ?

thanks
-- PMM

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Fri, May 08, 2026 at 11:31:13AM +0100, Peter Maydell wrote:

> On Fri, 8 May 2026 at 11:27, John Levon <john.levon@nutanix.com> wrote:
> >
> > This subsystem is no longer seeing any development, and the primary
> > contact listed as maintainer has confirmed they're dropping support of
> > it altogether.
> >
> > Signed-off-by: John Levon <john.levon@nutanix.com>
> > ---
> >  MAINTAINERS | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> If there's no longer interest in it, can/should we list it as deprecated
> in docs/about/deprecated.rst, so that we can remove it once the
> deprecation period has passed ?

Can you suggest what section this should go under? A new one maybe?

regards
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Peter Maydell]

On Fri, 8 May 2026 at 11:35, John Levon <john.levon@nutanix.com> wrote:
>
> On Fri, May 08, 2026 at 11:31:13AM +0100, Peter Maydell wrote:
>
> > On Fri, 8 May 2026 at 11:27, John Levon <john.levon@nutanix.com> wrote:
> > >
> > > This subsystem is no longer seeing any development, and the primary
> > > contact listed as maintainer has confirmed they're dropping support of
> > > it altogether.
> > >
> > > Signed-off-by: John Levon <john.levon@nutanix.com>
> > > ---
> > >  MAINTAINERS | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > If there's no longer interest in it, can/should we list it as deprecated
> > in docs/about/deprecated.rst, so that we can remove it once the
> > deprecation period has passed ?
>
> Can you suggest what section this should go under? A new one maybe?

Yeah, we don't have any existing obviously relevant section, so
I would create a new one "System emulator features" (with the same
"-----------" heading level and just above the existing
"System emulator CPUs" section).

-- PMM

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Philippe Mathieu-Daudé]

On 8/5/26 12:26, John Levon wrote:
> This subsystem is no longer seeing any development, and the primary
> contact listed as maintainer has confirmed they're dropping support of
> it altogether.
> 
> Signed-off-by: John Levon <john.levon@nutanix.com>
> ---
>   MAINTAINERS | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a90204ae9..ce2b494086 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
>   Multi-process QEMU
>   M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>   M: Jagannathan Raman <jag.raman@oracle.com>

But then shouldn't these 2 email entries be removed?

> -S: Maintained
> +S: Orphan
>   F: docs/devel/multi-process.rst
>   F: docs/system/multi-process.rst
>   F: hw/pci-host/remote.c

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

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

Confidential - Oracle Restricted \Including External Recipients





Confidential - Oracle Restricted \Including External Recipients

From: John Levon <john.levon@nutanix.com>
Date: Friday, May 8, 2026 at 6:27 AM
To: qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>; Jag Raman <jag.raman@oracle.com>; clg@redhat.com <clg@redhat.com>; John Levon <john.levon@nutanix.com>
Subject: [PATCH] Mark Multi-Process QEMU as Orphaned

This subsystem is no longer seeing any development, and the primary
contact listed as maintainer has confirmed they're dropping support of
it altogether.

Signed-off-by: John Levon <john.levon@nutanix.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a90204ae9..ce2b494086 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
 Multi-process QEMU
 M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
 M: Jagannathan Raman <jag.raman@oracle.com>
-S: Maintained
+S: Orphan
 F: docs/devel/multi-process.rst
 F: docs/system/multi-process.rst
 F: hw/pci-host/remote.c

Thanks for the reminder, John! I’ll send a PR shortly removing parts we are not longer using.

I got distracted from this task given some reorganization at my employer. I’ll send the patch out by tomorrow.

Thank you,
Jag

--
2.43.0


[-- Attachment #2: Type: text/html, Size: 3656 bytes --]

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Fri, May 08, 2026 at 02:21:37PM +0000, Jag Raman wrote:

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a90204ae9..ce2b494086 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
>  Multi-process QEMU
>  M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>  M: Jagannathan Raman <jag.raman@oracle.com>
> -S: Maintained
> +S: Orphan
>  F: docs/devel/multi-process.rst
>  F: docs/system/multi-process.rst
>  F: hw/pci-host/remote.c
> 
> Thanks for the reminder, John!

(Just for context, Cédric suggested this after my patch to update the
libvfio-user submodule for the compilation issues.)

> I’ll send a PR shortly removing parts we are not longer using.

QEMU maintainers can correct me, but I'd think it has to go through a
deprecation cycle first?

regards
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

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

Confidential - Oracle Restricted \Including External Recipients





Confidential - Oracle Restricted \Including External Recipients

From: John Levon <john.levon@nutanix.com>
Date: Friday, May 8, 2026 at 10:28 AM
To: Jag Raman <jag.raman@oracle.com>
Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org>; Elena Ufimtseva <elena.ufimtseva@oracle.com>; clg@redhat.com <clg@redhat.com>
Subject: Re: [PATCH] Mark Multi-Process QEMU as Orphaned

On Fri, May 08, 2026 at 02:21:37PM +0000, Jag Raman wrote:

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a90204ae9..ce2b494086 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
>  Multi-process QEMU
>  M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>  M: Jagannathan Raman <jag.raman@oracle.com>
> -S: Maintained
> +S: Orphan
>  F: docs/devel/multi-process.rst
>  F: docs/system/multi-process.rst
>  F: hw/pci-host/remote.c
>
> Thanks for the reminder, John!

(Just for context, Cédric suggested this after my patch to update the
libvfio-user submodule for the compilation issues.)

> I’ll send a PR shortly removing parts we are not longer using.

QEMU maintainers can correct me, but I'd think it has to go through a
deprecation cycle first?

If the code has to soak in a deprecated state, I think an “Obsolete” status
better fits it as it’s replaced by vfio-user.


regards
john

[-- Attachment #2: Type: text/html, Size: 3313 bytes --]

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Fri, May 08, 2026 at 02:33:59PM +0000, Jag Raman wrote:

>> QEMU maintainers can correct me, but I'd think it has to go through a
>> deprecation cycle first?
> 
> If the code has to soak in a deprecated state, I think an “Obsolete” status
> better fits it as it’s replaced by vfio-user.

Are you saying you and/or Elena are still maintaining the vfio-user
implementation in hw/remote ? As I don't think there's anything happening there
either.

regards
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Peter Maydell]

On Fri, 8 May 2026 at 15:29, John Levon <john.levon@nutanix.com> wrote:
>
> On Fri, May 08, 2026 at 02:21:37PM +0000, Jag Raman wrote:
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0a90204ae9..ce2b494086 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
> >  Multi-process QEMU
> >  M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> >  M: Jagannathan Raman <jag.raman@oracle.com>
> > -S: Maintained
> > +S: Orphan
> >  F: docs/devel/multi-process.rst
> >  F: docs/system/multi-process.rst
> >  F: hw/pci-host/remote.c
> >
> > Thanks for the reminder, John!
>
> (Just for context, Cédric suggested this after my patch to update the
> libvfio-user submodule for the compilation issues.)
>
> > I’ll send a PR shortly removing parts we are not longer using.
>
> QEMU maintainers can correct me, but I'd think it has to go through a
> deprecation cycle first?

That's generally correct. Apart from features which are clearly
unused because they were actually broken without anybody noticing,
we have a deprecation cycle where we first list the feature
in deprecated.rst; then it is in the deprecated state for
that release and the following one, and can be finally
removed in the one after that.

However in this case as I understand it the multiprocess
feature has always been "experimental" (as marked by the
machine and device names "x-remote", "x-pci-proxy-dev", etc
having an "x-" prefix). So if we really don't think this is
likely to be being used by anybody in practice I think the
experimental state allows us to remove it without waiting.
Dan, Paolo, what do you think ?

-- PMM

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Daniel P. Berrangé]

On Fri, May 08, 2026 at 03:39:35PM +0100, Peter Maydell wrote:
> On Fri, 8 May 2026 at 15:29, John Levon <john.levon@nutanix.com> wrote:
> >
> > On Fri, May 08, 2026 at 02:21:37PM +0000, Jag Raman wrote:
> >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 0a90204ae9..ce2b494086 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -4429,7 +4429,7 @@ F: tests/tcg/aarch64/system/semiheap.c
> > >  Multi-process QEMU
> > >  M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> > >  M: Jagannathan Raman <jag.raman@oracle.com>
> > > -S: Maintained
> > > +S: Orphan
> > >  F: docs/devel/multi-process.rst
> > >  F: docs/system/multi-process.rst
> > >  F: hw/pci-host/remote.c
> > >
> > > Thanks for the reminder, John!
> >
> > (Just for context, Cédric suggested this after my patch to update the
> > libvfio-user submodule for the compilation issues.)
> >
> > > I’ll send a PR shortly removing parts we are not longer using.
> >
> > QEMU maintainers can correct me, but I'd think it has to go through a
> > deprecation cycle first?
> 
> That's generally correct. Apart from features which are clearly
> unused because they were actually broken without anybody noticing,
> we have a deprecation cycle where we first list the feature
> in deprecated.rst; then it is in the deprecated state for
> that release and the following one, and can be finally
> removed in the one after that.
> 
> However in this case as I understand it the multiprocess
> feature has always been "experimental" (as marked by the
> machine and device names "x-remote", "x-pci-proxy-dev", etc
> having an "x-" prefix). So if we really don't think this is
> likely to be being used by anybody in practice I think the
> experimental state allows us to remove it without waiting.
> Dan, Paolo, what do you think ?

If it was always marked experimental, then we do not need to apply the
deprecation process, though the maintainers can choose to do so at their
discretion.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jagannathan Raman]

On 5/8/26 10:37 AM, John Levon wrote:
> On Fri, May 08, 2026 at 02:33:59PM +0000, Jag Raman wrote:
>
>>> QEMU maintainers can correct me, but I'd think it has to go through a
>>> deprecation cycle first?
>> If the code has to soak in a deprecated state, I think an “Obsolete” status
>> better fits it as it’s replaced by vfio-user.
> Are you saying you and/or Elena are still maintaining the vfio-user
> implementation in hw/remote ? As I don't think there's anything happening there
> either.

The vfio-user implementation is the server part of the vfio-user client 
and it utilizes
the x-remote machine object. I do maintain it - I proposed a fix to bug 
last week and
reviewed an alternative proposal from Marc-Andre. But if no one is using 
it, I'm OK
with removing this support from QEMU.

There's no active development on it due to a lack of inbound feature 
requests. Are
you looking for any specific features?

If you want to bring the maintenance of this under your purview, I'm OK 
with that also.

Thanks,
Jag

>
> regards
> john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Fri, May 08, 2026 at 11:07:28AM -0400, Jagannathan Raman wrote:

> On 5/8/26 10:37 AM, John Levon wrote:
> > On Fri, May 08, 2026 at 02:33:59PM +0000, Jag Raman wrote:
> > 
> > > > QEMU maintainers can correct me, but I'd think it has to go through a
> > > > deprecation cycle first?
> > > If the code has to soak in a deprecated state, I think an “Obsolete” status
> > > better fits it as it’s replaced by vfio-user.
> > Are you saying you and/or Elena are still maintaining the vfio-user
> > implementation in hw/remote ? As I don't think there's anything happening there
> > either.
> 
> The vfio-user implementation is the server part of the vfio-user client and it
> utilizes the x-remote machine object. I do maintain it - I proposed a fix to
> bug last week and reviewed an alternative proposal from Marc-Andre.

When I was asking you about mpqemu, I was talking about all of hw/remote, not
just the legacy backend. Apologies if I misunderstood you.

I think "S: Odd Fixes" is more appropriate (see below).

> There's no active development on it due to a lack of inbound feature requests.
> Are you looking for any specific features?

Confused by this comment, as we've discussed before several times that you were
going to migrate the testing across to vfio-user instead of the legacy protocol,
then remove the legacy protocol altogether.

Then no patches arrived, so I presume that's not going to happen.

> If you want to bring the maintenance of this under your purview, I'm OK with

I don't have cycles/interest for this unfortunately.


How about the following:

1) mark the whole subsystem as Odd Fixes

2) mark the legacy backend as Obsolete

3) if we don't see any further work on converting mpqemu over to vfio-user
properly over, say, the next calendar year, then remove the whole feature.

regards
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jagannathan Raman]

On 5/8/26 11:19 AM, John Levon wrote:
> On Fri, May 08, 2026 at 11:07:28AM -0400, Jagannathan Raman wrote:
>
>> On 5/8/26 10:37 AM, John Levon wrote:
>>> On Fri, May 08, 2026 at 02:33:59PM +0000, Jag Raman wrote:
>>>
>>>>> QEMU maintainers can correct me, but I'd think it has to go through a
>>>>> deprecation cycle first?
>>>> If the code has to soak in a deprecated state, I think an “Obsolete” status
>>>> better fits it as it’s replaced by vfio-user.
>>> Are you saying you and/or Elena are still maintaining the vfio-user
>>> implementation in hw/remote ? As I don't think there's anything happening there
>>> either.
>> The vfio-user implementation is the server part of the vfio-user client and it
>> utilizes the x-remote machine object. I do maintain it - I proposed a fix to
>> bug last week and reviewed an alternative proposal from Marc-Andre.
> When I was asking you about mpqemu, I was talking about all of hw/remote, not
> just the legacy backend. Apologies if I misunderstood you.
>
> I think "S: Odd Fixes" is more appropriate (see below).
Reclassifying the status as "Odd Fixes" is accurate.
>
>> There's no active development on it due to a lack of inbound feature requests.
>> Are you looking for any specific features?
> Confused by this comment, as we've discussed before several times that you were
> going to migrate the testing across to vfio-user instead of the legacy protocol,
> then remove the legacy protocol altogether.
>
> Then no patches arrived, so I presume that's not going to happen.

My employer's resource allocation has de-prioritized this. So, I'll do 
this during my personal time.

I'll focus on these two items during this weekend. Do you need anything 
else?

>
>> If you want to bring the maintenance of this under your purview, I'm OK with
> I don't have cycles/interest for this unfortunately.
>
>
> How about the following:
>
> 1) mark the whole subsystem as Odd Fixes
>
> 2) mark the legacy backend as Obsolete
>
> 3) if we don't see any further work on converting mpqemu over to vfio-user
> properly over, say, the next calendar year, then remove the whole feature.

The above strategy sounds good to me.

Thanks!

>
> regards
> john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Fri, May 08, 2026 at 11:35:25AM -0400, Jagannathan Raman wrote:

> > > There's no active development on it due to a lack of inbound feature requests.
> > > Are you looking for any specific features?
> > Confused by this comment, as we've discussed before several times that you were
> > going to migrate the testing across to vfio-user instead of the legacy protocol,
> > then remove the legacy protocol altogether.
> > 
> > Then no patches arrived, so I presume that's not going to happen.
> 
> My employer's resource allocation has de-prioritized this. So, I'll do this
> during my personal time.

Sounds good, thanks!

regards
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Paolo Bonzini]

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

Il ven 8 mag 2026, 16:39 Peter Maydell <peter.maydell@linaro.org> ha
scritto:

> However in this case as I understand it the multiprocess
> feature has always been "experimental" (as marked by the
> machine and device names "x-remote", "x-pci-proxy-dev", etc
> having an "x-" prefix). So if we really don't think this is
> likely to be being used by anybody in practice I think the
> experimental state allows us to remove it without waiting.
> Dan, Paolo, what do you think ?
>

Indeed I was going to propose instantly removing it.

Paolo


> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 1280 bytes --]

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

> Confused by this comment, as we've discussed before several times that you were
> going to migrate the testing across to vfio-user instead of the legacy protocol,
> then remove the legacy protocol altogether.

John, just to double-check, we want the functional test to use the vfio-user client
and use the x-remote object as the remote server, is that correct?

Thanks,
Jag

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Mon, May 11, 2026 at 04:15:14PM +0000, Jag Raman wrote:

> > Confused by this comment, as we've discussed before several times that you were
> > going to migrate the testing across to vfio-user instead of the legacy protocol,
> > then remove the legacy protocol altogether.
> 
> John, just to double-check, we want the functional test to use the vfio-user client
> and use the x-remote object as the remote server, is that correct?

-machine x-remote,vfio-user=on

I think, which is what uses vfio-user between the two qemu instead of the
MPQEMU_* messages etc, right?

Then we can at some point look at retiring the non-vfio-user implementation.

thanks
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

> On May 11, 2026, at 12:25 PM, John Levon <john.levon@nutanix.com> wrote:
> 
> On Mon, May 11, 2026 at 04:15:14PM +0000, Jag Raman wrote:
> 
>>> Confused by this comment, as we've discussed before several times that you were
>>> going to migrate the testing across to vfio-user instead of the legacy protocol,
>>> then remove the legacy protocol altogether.
>> 
>> John, just to double-check, we want the functional test to use the vfio-user client
>> and use the x-remote object as the remote server, is that correct?
> 
> -machine x-remote,vfio-user=on
> 
> I think, which is what uses vfio-user between the two qemu instead of the
> MPQEMU_* messages etc, right?
> 
> Then we can at some point look at retiring the non-vfio-user implementation.

Makes sense, thank you!

> 
> thanks
> john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Cédric Le Goater]

Hi,

>> How about the following:
>>
>> 1) mark the whole subsystem as Odd Fixes
>>
>> 2) mark the legacy backend as Obsolete
>>
>> 3) if we don't see any further work on converting mpqemu over to vfio-user
>> properly over, say, the next calendar year, then remove the whole feature.
> 
> The above strategy sounds good to me.
> 
> Thanks!
> 
Were changes sent for step 1,2 ?

Thanks,

C.

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

> On May 21, 2026, at 4:24 AM, Cédric Le Goater <clg@redhat.com> wrote:
> 
> Hi,
> 
>>> How about the following:
>>> 
>>> 1) mark the whole subsystem as Odd Fixes
>>> 
>>> 2) mark the legacy backend as Obsolete
>>> 
>>> 3) if we don't see any further work on converting mpqemu over to vfio-user
>>> properly over, say, the next calendar year, then remove the whole feature.
>> The above strategy sounds good to me.
>> Thanks!
> Were changes sent for step 1,2 ?

Hi Cedric,

Thanks for checking. I was batching this patch with another pending task, but I’ve just sent it out in case you’re tracking this separately.

Jag

> 
> Thanks,
> 
> C.
> 

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

> 
> 3) if we don't see any further work on converting mpqemu over to vfio-user
> properly over, say, the next calendar year, then remove the whole feature.

To switch the functional test to use vfio-user, we need to enable the x-vfio-user-server object by default using --enable-vfio-user-server. Is that OK?

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[John Levon]

On Fri, May 22, 2026 at 08:48:03PM +0000, Jag Raman wrote:

> > 3) if we don't see any further work on converting mpqemu over to vfio-user
> > properly over, say, the next calendar year, then remove the whole feature.
> 
> To switch the functional test to use vfio-user, we need to enable the
> x-vfio-user-server object by default using --enable-vfio-user-server. Is that
> OK?

Presumably you can enable it by default if --enable-multiprocess is set?

regards
john

Re: [PATCH] Mark Multi-Process QEMU as Orphaned

[Jag Raman]

> On May 26, 2026, at 5:04 AM, John Levon <john.levon@nutanix.com> wrote:
> 
> On Fri, May 22, 2026 at 08:48:03PM +0000, Jag Raman wrote:
> 
>>> 3) if we don't see any further work on converting mpqemu over to vfio-user
>>> properly over, say, the next calendar year, then remove the whole feature.
>> 
>> To switch the functional test to use vfio-user, we need to enable the
>> x-vfio-user-server object by default using --enable-vfio-user-server. Is that
>> OK?
> 
> Presumably you can enable it by default if --enable-multiprocess is set?

I agree. We didn’t enable x-vfio-user-server by default because the vfio-user
client wasn’t ready at the time. Now that the vfio-user client is available,
we can enable vfio-user-server and turn off multiprocess by default.

Thanks,
Jag

> 
> regards
> john
>