Re: [PATCH] Mark Multi-Process QEMU as Orphaned
> On May 26, 2026, at 5:04 AM, John Levon wrote: > > On Fri, May 22, 2026 at 08:48:03PM +, 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 >
Re: [PATCH] Mark Multi-Process QEMU as Orphaned
On Fri, May 22, 2026 at 08:48:03PM +, 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
> > 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
> On May 21, 2026, at 4:24 AM, Cédric Le Goater 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
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
> On May 11, 2026, at 12:25 PM, John Levon wrote: > > On Mon, May 11, 2026 at 04:15:14PM +, 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
On Mon, May 11, 2026 at 04:15:14PM +, 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
> 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
Il ven 8 mag 2026, 16:39 Peter Maydell 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 > >
Re: [PATCH] Mark Multi-Process QEMU as Orphaned
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
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 +, 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
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 +, 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
On 5/8/26 10:37 AM, John Levon wrote: On Fri, May 08, 2026 at 02:33:59PM +, 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
On Fri, May 08, 2026 at 03:39:35PM +0100, Peter Maydell wrote: > On Fri, 8 May 2026 at 15:29, John Levon wrote: > > > > On Fri, May 08, 2026 at 02:21:37PM +, 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 > > > M: Jagannathan Raman > > > -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
On Fri, 8 May 2026 at 15:29, John Levon wrote: > > On Fri, May 08, 2026 at 02:21:37PM +, 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 > > M: Jagannathan Raman > > -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
On Fri, May 08, 2026 at 02:33:59PM +, 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
Confidential - Oracle Restricted \Including External Recipients Confidential - Oracle Restricted \Including External Recipients From: John Levon Date: Friday, May 8, 2026 at 10:28 AM To: Jag Raman Cc: [email protected] ; Elena Ufimtseva ; [email protected] Subject: Re: [PATCH] Mark Multi-Process QEMU as Orphaned On Fri, May 08, 2026 at 02:21:37PM +, 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 > M: Jagannathan Raman > -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
Re: [PATCH] Mark Multi-Process QEMU as Orphaned
On Fri, May 08, 2026 at 02:21:37PM +, 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 > M: Jagannathan Raman > -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
Confidential - Oracle Restricted \Including External Recipients Confidential - Oracle Restricted \Including External Recipients From: John Levon Date: Friday, May 8, 2026 at 6:27 AM To: [email protected] Cc: Elena Ufimtseva ; Jag Raman ; [email protected] ; John Levon 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 --- 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 M: Jagannathan Raman -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
Re: [PATCH] Mark Multi-Process QEMU as Orphaned
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 --- 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 M: Jagannathan Raman 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
On Fri, 8 May 2026 at 11:35, John Levon wrote: > > On Fri, May 08, 2026 at 11:31:13AM +0100, Peter Maydell wrote: > > > On Fri, 8 May 2026 at 11:27, 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 > > > --- > > > 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
On Fri, May 08, 2026 at 11:31:13AM +0100, Peter Maydell wrote: > On Fri, 8 May 2026 at 11:27, 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 > > --- > > 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
On Fri, 8 May 2026 at 11:27, 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 > --- > 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
