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.0Confidential - 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
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
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
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 > >
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 :|
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
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
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
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
> > 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?
> 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
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
> 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
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
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.
> 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. >
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.