* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 @ 2019-08-19 21:46 Josh Kunz via Qemu-devel 2019-08-21 9:28 ` Laurent Vivier 0 siblings, 1 reply; 15+ messages in thread From: Josh Kunz via Qemu-devel @ 2019-08-19 21:46 UTC (permalink / raw) To: marlies.ruck, qemu-devel, riku.voipio, laurent Cc: qemu-trivial, peter.maydell, Shu-Chun Weng Hi all, I have also experienced issues with SIGRTMIN + 1, and am interested in moving this patch forwards. Anything I can do here to help? Would the maintainers prefer myself or Marli re-submit the patch? The Go issue here seems particularly sticky. Even if we update the Go runtime, users may try and run older binaries built with older versions of Go for quite some time (months? years?). Would it be better to hide this behind some kind of build-time flag (`--enable-sigrtmin-plus-one-proxy` or something), so that some users can opt-in, but older binaries still work as expected? Also, here is a link to the original thread this message is in reply to in-case my mail-client doesn't set up the reply properly: https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html Thanks, Josh Kunz ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-19 21:46 [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 Josh Kunz via Qemu-devel @ 2019-08-21 9:28 ` Laurent Vivier 2019-08-26 21:10 ` Josh Kunz via Qemu-devel 0 siblings, 1 reply; 15+ messages in thread From: Laurent Vivier @ 2019-08-21 9:28 UTC (permalink / raw) To: Josh Kunz, marlies.ruck, qemu-devel, riku.voipio Cc: peter.maydell, qemu-trivial, Aleksandar Markovic, Aleksandar Markovic, milos.stojanovic, Shu-Chun Weng Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > Hi all, > > I have also experienced issues with SIGRTMIN + 1, and am interested in > moving this patch forwards. Anything I can do here to help? Would the > maintainers prefer myself or Marli re-submit the patch? > > The Go issue here seems particularly sticky. Even if we update the Go > runtime, users may try and run older binaries built with older versions of > Go for quite some time (months? years?). Would it be better to hide this > behind some kind of build-time flag (`--enable-sigrtmin-plus-one-proxy` or > something), so that some users can opt-in, but older binaries still work as > expected? > > Also, here is a link to the original thread this message is in reply to > in-case my mail-client doesn't set up the reply properly: > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html The problem here is we break something to fix something else. I'm wondering if the series from Aleksandar Markovic, "linux-user: Support signal passing for targets having more signals than host" [1] can fix the problem in a better way? Thanks, Laurent [1] http://patchwork.ozlabs.org/cover/1103565/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-21 9:28 ` Laurent Vivier @ 2019-08-26 21:10 ` Josh Kunz via Qemu-devel 2019-08-27 8:08 ` Peter Maydell 2019-08-28 8:51 ` Laurent Vivier 0 siblings, 2 replies; 15+ messages in thread From: Josh Kunz via Qemu-devel @ 2019-08-26 21:10 UTC (permalink / raw) To: Laurent Vivier Cc: Peter Maydell, qemu-trivial, riku.voipio, qemu-devel, Aleksandar Markovic, marlies.ruck, Aleksandar Markovic, milos.stojanovic, Shu-Chun Weng On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu> wrote: > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > Hi all, > > > > I have also experienced issues with SIGRTMIN + 1, and am interested in > > moving this patch forwards. Anything I can do here to help? Would the > > maintainers prefer myself or Marli re-submit the patch? > > > > The Go issue here seems particularly sticky. Even if we update the Go > > runtime, users may try and run older binaries built with older versions > of > > Go for quite some time (months? years?). Would it be better to hide this > > behind some kind of build-time flag (`--enable-sigrtmin-plus-one-proxy` > or > > something), so that some users can opt-in, but older binaries still work > as > > expected? > > > > Also, here is a link to the original thread this message is in reply to > > in-case my mail-client doesn't set up the reply properly: > > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html > > The problem here is we break something to fix something else. > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > Support signal passing for targets having more signals than host" [1] > can fix the problem in a better way? > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) does not directly fix the issue addressed by this patch (re-wiring SIGRTMIN+1), but since it basically implements generic signal multiplexing, it could be re-worked to address this case as well. The way it handles `si_code` spooks me a little bit. It could easily be broken by a kernel version change, and such a breakage could be hard to detect or lead to surprising results. Other than that, it looks like a reasonable implementation. That said, overall, fixing the SIGRTMIN+1 issue using a more-generic signal-multiplexing mechanism doesn't seem *that* much better to me. It adds a lot of complexity, and only saves a single signal (assuming glibc doesn't add more reserved signals). The "big win" is additional emulation features, like those introduced in MUX patch (being able to utilize signals outside of the host range). If having those features in QEMU warrants the additional complexity, then re-working this patch on-top of that infrastructure seems like a good idea. If the maintainers want to go down that route, then I would be happy to re-work this patch utilizing the infrastructure from the MUX patch. Unfortunately it will require non-trivial changes, so it may be best to wait until that patch is merged. I could also provide a patch "on top of" the MUX patch, if that's desired/more convenient. Just one last note, if you do decide to merge the MUX patch, then it would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the multiplexing signal if possible, to avoid breaking go binaries. Thanks again for taking a look at this issue. Cheers, Josh Kunz [1] http://patchwork.ozlabs.org/cover/1103565/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-26 21:10 ` Josh Kunz via Qemu-devel @ 2019-08-27 8:08 ` Peter Maydell 2019-08-28 8:51 ` Laurent Vivier 1 sibling, 0 replies; 15+ messages in thread From: Peter Maydell @ 2019-08-27 8:08 UTC (permalink / raw) To: Josh Kunz Cc: QEMU Trivial, Riku Voipio, Laurent Vivier, QEMU Developers, Aleksandar Markovic, Marlies Ruck, Aleksandar Markovic, Miloš Stojanović, Shu-Chun Weng On Mon, 26 Aug 2019 at 22:10, Josh Kunz <jkz@google.com> wrote: > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic signal-multiplexing mechanism doesn't seem *that* much better to me. It adds a lot of complexity, and only saves a single signal (assuming glibc doesn't add more reserved signals). The "big win" is additional emulation features, like those introduced in MUX patch (being able to utilize signals outside of the host range). If having those features in QEMU warrants the additional complexity, then re-working this patch on-top of that infrastructure seems like a good idea. It has the huge advantage that it doesn't break existing working binaries. That's the main reason we've never applied the 'just swap another couple of signals' patch. The other possible approach for avoiding binary breakage would be to silently ignore attempts to set handlers for the signals QEMU uses, rather than failing them. I'm not sure what fallout that might have, though... thanks -- PMM ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-26 21:10 ` Josh Kunz via Qemu-devel 2019-08-27 8:08 ` Peter Maydell @ 2019-08-28 8:51 ` Laurent Vivier 2019-08-28 17:31 ` [Qemu-devel] [EXTERNAL]Re: " Aleksandar Markovic 1 sibling, 1 reply; 15+ messages in thread From: Laurent Vivier @ 2019-08-28 8:51 UTC (permalink / raw) To: Josh Kunz, Aleksandar Markovic, milos.stojanovic Cc: Peter Maydell, qemu-trivial, riku.voipio, qemu-devel, marlies.ruck, Aleksandar Markovic, Shu-Chun Weng Le 26/08/2019 à 23:10, Josh Kunz a écrit : > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu > <mailto:laurent@vivier.eu>> wrote: > > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > Hi all, > > > > I have also experienced issues with SIGRTMIN + 1, and am interested in > > moving this patch forwards. Anything I can do here to help? Would the > > maintainers prefer myself or Marli re-submit the patch? > > > > The Go issue here seems particularly sticky. Even if we update the Go > > runtime, users may try and run older binaries built with older > versions of > > Go for quite some time (months? years?). Would it be better to > hide this > > behind some kind of build-time flag > (`--enable-sigrtmin-plus-one-proxy` or > > something), so that some users can opt-in, but older binaries > still work as > > expected? > > > > Also, here is a link to the original thread this message is in > reply to > > in-case my mail-client doesn't set up the reply properly: > > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html > > The problem here is we break something to fix something else. > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > Support signal passing for targets having more signals than host" [1] > can fix the problem in a better way? > > > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) > does not directly fix the issue addressed by this patch (re-wiring > SIGRTMIN+1), but since it basically implements generic signal > multiplexing, it could be re-worked to address this case as well. The > way it handles `si_code` spooks me a little bit. It could easily be > broken by a kernel version change, and such a breakage could be hard to > detect or lead to surprising results. Other than that, it looks like a > reasonable implementation. > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic > signal-multiplexing mechanism doesn't seem *that* much better to me. It > adds a lot of complexity, and only saves a single signal (assuming glibc > doesn't add more reserved signals). The "big win" is additional > emulation features, like those introduced in MUX patch (being able to > utilize signals outside of the host range). If having those features in > QEMU warrants the additional complexity, then re-working this patch > on-top of that infrastructure seems like a good idea. > > If the maintainers want to go down that route, then I would be happy to > re-work this patch utilizing the infrastructure from the MUX patch. > Unfortunately it will require non-trivial changes, so it may be best to > wait until that patch is merged. I could also provide a patch "on top > of" the MUX patch, if that's desired/more convenient. > > Just one last note, if you do decide to merge the MUX patch, then it > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the > multiplexing signal if possible, to avoid breaking go binaries. > Personally, I prefer a solution that breaks nothing. Aleksandar, Milos, do you have an updated version of you series "Support signal passing for targets having more signals than host"? Thanks, Laurent ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] [EXTERNAL]Re: patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-28 8:51 ` Laurent Vivier @ 2019-08-28 17:31 ` Aleksandar Markovic 2019-08-31 1:26 ` Josh Kunz via Qemu-devel 2019-12-07 13:05 ` Aleksandar Markovic 0 siblings, 2 replies; 15+ messages in thread From: Aleksandar Markovic @ 2019-08-28 17:31 UTC (permalink / raw) To: Laurent Vivier, Josh Kunz, Aleksandar Markovic, milos.stojanovic, Petar Jovanovic Cc: Peter Maydell, qemu-trivial, riku.voipio, qemu-devel, marlies.ruck, Shu-Chun Weng > From: Laurent Vivier <laurent@vivier.eu> > Sent: Wednesday, August 28, 2019 10:51 AM > To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com > Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi; > qemu-trivial@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar Markovic > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 > > Le 26/08/2019 à 23:10, Josh Kunz a écrit : > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu > > <mailto:laurent@vivier.eu>> wrote: > > > > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > > Hi all, > > > > > > I have also experienced issues with SIGRTMIN + 1, and am interested in > > > moving this patch forwards. Anything I can do here to help? Would the > > > maintainers prefer myself or Marli re-submit the patch? > > > > > > The Go issue here seems particularly sticky. Even if we update the Go > > > runtime, users may try and run older binaries built with older > > versions of > > > Go for quite some time (months? years?). Would it be better to > > hide this > > > behind some kind of build-time flag > > (`--enable-sigrtmin-plus-one-proxy` or > > > something), so that some users can opt-in, but older binaries > > still work as > > > expected? > > > > > > Also, here is a link to the original thread this message is in > > reply to > > > in-case my mail-client doesn't set up the reply properly: > > > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html > > > > The problem here is we break something to fix something else. > > > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > > Support signal passing for targets having more signals than host" [1] > > can fix the problem in a better way? > > > > > > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) > > does not directly fix the issue addressed by this patch (re-wiring > > SIGRTMIN+1), but since it basically implements generic signal > > multiplexing, it could be re-worked to address this case as well. The > > way it handles `si_code` spooks me a little bit. It could easily be > > broken by a kernel version change, and such a breakage could be hard to > > detect or lead to surprising results. Other than that, it looks like a > > reasonable implementation. > > > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic > > signal-multiplexing mechanism doesn't seem *that* much better to me. It > > adds a lot of complexity, and only saves a single signal (assuming glibc > > doesn't add more reserved signals). The "big win" is additional > > emulation features, like those introduced in MUX patch (being able to > > utilize signals outside of the host range). If having those features in > > QEMU warrants the additional complexity, then re-working this patch > > on-top of that infrastructure seems like a good idea. > > > > If the maintainers want to go down that route, then I would be happy to > > re-work this patch utilizing the infrastructure from the MUX patch. > > Unfortunately it will require non-trivial changes, so it may be best to > > wait until that patch is merged. I could also provide a patch "on top > > of" the MUX patch, if that's desired/more convenient. > > > > Just one last note, if you do decide to merge the MUX patch, then it > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the > > multiplexing signal if possible, to avoid breaking go binaries. > > > > Personally, I prefer a solution that breaks nothing. > > Aleksandar, Milos, > > do you have an updated version of you series "Support signal passing for > targets having more signals than host"? > Milos is unfortunetely working on an entirely different project now, and can't spare enough time to finish the series. I am also busy with other issues, even though I would like very much this or equivalent solution to be integrated. Alternatively, someone in the team may have time later this year, but I do not know that yet - perhaps somebody else (Josh) can take over the series? Sincerely, Aleksandar > Thanks, > Laurent > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] [EXTERNAL]Re: patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-28 17:31 ` [Qemu-devel] [EXTERNAL]Re: " Aleksandar Markovic @ 2019-08-31 1:26 ` Josh Kunz via Qemu-devel 2019-10-02 18:06 ` [EXTERNAL]Re: [Qemu-devel] " Josh Kunz 2019-12-07 13:05 ` Aleksandar Markovic 1 sibling, 1 reply; 15+ messages in thread From: Josh Kunz via Qemu-devel @ 2019-08-31 1:26 UTC (permalink / raw) To: Aleksandar Markovic Cc: Peter Maydell, qemu-trivial, riku.voipio, qemu-devel, Laurent Vivier, Aleksandar Markovic, marlies.ruck, Petar Jovanovic, milos.stojanovic, Shu-Chun Weng I can take over the series. I'll rebase the patch set, and update it to address the SIGRTMIN - 1 issue. I should have an update sometime next week. On Wed, Aug 28, 2019 at 10:31 AM Aleksandar Markovic <amarkovic@wavecomp.com> wrote: > > From: Laurent Vivier <laurent@vivier.eu> > > Sent: Wednesday, August 28, 2019 10:51 AM > > To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com > > Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi; > > qemu-trivial@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar > Markovic > > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and > SIGRTMAX - 1 > > > > Le 26/08/2019 à 23:10, Josh Kunz a écrit : > > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu > > > <mailto:laurent@vivier.eu>> wrote: > > > > > > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > > > Hi all, > > > > > > > > I have also experienced issues with SIGRTMIN + 1, and am > interested in > > > > moving this patch forwards. Anything I can do here to help? > Would the > > > > maintainers prefer myself or Marli re-submit the patch? > > > > > > > > The Go issue here seems particularly sticky. Even if we update > the Go > > > > runtime, users may try and run older binaries built with older > > > versions of > > > > Go for quite some time (months? years?). Would it be better to > > > hide this > > > > behind some kind of build-time flag > > > (`--enable-sigrtmin-plus-one-proxy` or > > > > something), so that some users can opt-in, but older binaries > > > still work as > > > > expected? > > > > > > > > Also, here is a link to the original thread this message is in > > > reply to > > > > in-case my mail-client doesn't set up the reply properly: > > > > > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html > > > > > > The problem here is we break something to fix something else. > > > > > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > > > Support signal passing for targets having more signals than host" > [1] > > > can fix the problem in a better way? > > > > > > > > > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) > > > does not directly fix the issue addressed by this patch (re-wiring > > > SIGRTMIN+1), but since it basically implements generic signal > > > multiplexing, it could be re-worked to address this case as well. The > > > way it handles `si_code` spooks me a little bit. It could easily be > > > broken by a kernel version change, and such a breakage could be hard to > > > detect or lead to surprising results. Other than that, it looks like a > > > reasonable implementation. > > > > > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic > > > signal-multiplexing mechanism doesn't seem *that* much better to me. It > > > adds a lot of complexity, and only saves a single signal (assuming > glibc > > > doesn't add more reserved signals). The "big win" is additional > > > emulation features, like those introduced in MUX patch (being able to > > > utilize signals outside of the host range). If having those features in > > > QEMU warrants the additional complexity, then re-working this patch > > > on-top of that infrastructure seems like a good idea. > > > > > > If the maintainers want to go down that route, then I would be happy to > > > re-work this patch utilizing the infrastructure from the MUX patch. > > > Unfortunately it will require non-trivial changes, so it may be best to > > > wait until that patch is merged. I could also provide a patch "on top > > > of" the MUX patch, if that's desired/more convenient. > > > > > > Just one last note, if you do decide to merge the MUX patch, then it > > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the > > > multiplexing signal if possible, to avoid breaking go binaries. > > > > > > > Personally, I prefer a solution that breaks nothing. > > > > Aleksandar, Milos, > > > > do you have an updated version of you series "Support signal passing for > > targets having more signals than host"? > > > > Milos is unfortunetely working on an entirely different project now, and > can't spare enough time to finish the series. I am also busy with other > issues, even though I would like very much this or equivalent solution to > be integrated. Alternatively, someone in the team may have time later this > year, but I do not know that yet - perhaps somebody else (Josh) can take > over the series? > > Sincerely, > Aleksandar > > > > Thanks, > > Laurent > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-31 1:26 ` Josh Kunz via Qemu-devel @ 2019-10-02 18:06 ` Josh Kunz 0 siblings, 0 replies; 15+ messages in thread From: Josh Kunz @ 2019-10-02 18:06 UTC (permalink / raw) To: Aleksandar Markovic Cc: Laurent Vivier, Aleksandar Markovic, milos.stojanovic, Petar Jovanovic, marlies.ruck, qemu-devel, riku.voipio, qemu-trivial, Peter Maydell, Shu-Chun Weng [-- Attachment #1: Type: text/plain, Size: 8280 bytes --] So, this turned out to be much more complicated than I initially expected. The current linux-user signal-handling implementation makes the assumption that there is a 1:1 correspondence between host signals, and target (guest) signals in a whole bunch of places. Breaking this assumption breaks a lot of the signal handling code. I’m no longer sure that “multiplexing” is a good solution. Here are some of the issues I’ve run into while implementing this patch: * Signal masks no longer work. The existing signal handling routines assume that target masks can be translated into equivalent host masks, but if multiple target signals map to a single host signal, the masks are no longer equivalent. This can be addressed by maintaining a separate emulated target signal mask (which is checked in process_pending_signals). Note: this is largely addressed by Milos/Aleksandar's patch. * sigaction no longer works. Right now, even though SIGRTMIN is mapped to SIGRTMAX, we are still allowed to do a “sigaction” on the signal. Without a 1:1 mapping, the action table must be fully emulated. * Syscall interruption (SA_RESTART and EINTR) breaks. Emulating the signal action table means that QEMU must now implement SA_RESTART behavior (we can’t rely on the kernel to do this), which will require changes to most syscalls. * sigsuspend breaks. To avoid masking too many signals with a sigsuspend, the host mask used for “sigsuspend” cannot block the multiplexing signal. This means that the sigsuspend handler may get interrupted by a multiplexed signal that is supposed to be masked by the target. Linux user-mode will have to support signal queueing to track pending RT signals. * signalfd breaks. If the user includes a multiplexed signal in the “signalfd” set, then signalfd behavior will have to be fully emulated. The only way I can think to support this is by either completely emulating FDs, or by using something like “eventfd” or “memfd” to make a fake signalfd (that still works with select), and then injecting siginfo structures when the fake FD is read. Not pretty. * sigtimedwait breaks. The given (target) sigset will not have an equivalent host sigset if some target signals are multiplexed. The host sigset will either be too large (possibly receiving some signals that should remain pending), or too small (missing signals that fulfil the target’s criteria, which is unacceptable). This can be worked-around by re-queuing signals and using -TARGET_ERESTARTSYS, but it’s quite complicated to make this appear atomic. These are just the things I have found so far. I’m not sure if this is everything that is required to add actual signal multiplexing support. If QEMU follows through with signal multiplexing, it will be a big change to QEMU signal handling. Full emulation of these signal aspects will bring QEMU further away from kernel behavior, and introduce the possibility of bugs or incompatibilities in QEMU’s signal-handling layer. To support signals outside the host range, this is unavoidable; but for the SIGRTMIN, SIGRTMIN+1 case, I’m not sure it’s worth it. After considering these drawbacks, do the QEMU maintainers still think this is the right approach for handling these libc reserved signals? On Fri, Aug 30, 2019 at 6:26 PM Josh Kunz <jkz@google.com> wrote: > I can take over the series. I'll rebase the patch set, and update it to > address the SIGRTMIN - 1 issue. I should have an update sometime next week. > > On Wed, Aug 28, 2019 at 10:31 AM Aleksandar Markovic < > amarkovic@wavecomp.com> wrote: > >> > From: Laurent Vivier <laurent@vivier.eu> >> > Sent: Wednesday, August 28, 2019 10:51 AM >> > To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com >> > Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi; >> > qemu-trivial@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar >> Markovic >> > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and >> SIGRTMAX - 1 >> > >> > Le 26/08/2019 à 23:10, Josh Kunz a écrit : >> > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu >> > > <mailto:laurent@vivier.eu>> wrote: >> > > >> > > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : >> > > > Hi all, >> > > > >> > > > I have also experienced issues with SIGRTMIN + 1, and am >> interested in >> > > > moving this patch forwards. Anything I can do here to help? >> Would the >> > > > maintainers prefer myself or Marli re-submit the patch? >> > > > >> > > > The Go issue here seems particularly sticky. Even if we update >> the Go >> > > > runtime, users may try and run older binaries built with older >> > > versions of >> > > > Go for quite some time (months? years?). Would it be better to >> > > hide this >> > > > behind some kind of build-time flag >> > > (`--enable-sigrtmin-plus-one-proxy` or >> > > > something), so that some users can opt-in, but older binaries >> > > still work as >> > > > expected? >> > > > >> > > > Also, here is a link to the original thread this message is in >> > > reply to >> > > > in-case my mail-client doesn't set up the reply properly: >> > > > >> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html >> > > >> > > The problem here is we break something to fix something else. >> > > >> > > I'm wondering if the series from Aleksandar Markovic, "linux-user: >> > > Support signal passing for targets having more signals than host" >> [1] >> > > can fix the problem in a better way? >> > > >> > > >> > > That patch[1] (which I'll refer to as the MUX patch to avoid >> confusion) >> > > does not directly fix the issue addressed by this patch (re-wiring >> > > SIGRTMIN+1), but since it basically implements generic signal >> > > multiplexing, it could be re-worked to address this case as well. The >> > > way it handles `si_code` spooks me a little bit. It could easily be >> > > broken by a kernel version change, and such a breakage could be hard >> to >> > > detect or lead to surprising results. Other than that, it looks like a >> > > reasonable implementation. >> > > >> > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic >> > > signal-multiplexing mechanism doesn't seem *that* much better to me. >> It >> > > adds a lot of complexity, and only saves a single signal (assuming >> glibc >> > > doesn't add more reserved signals). The "big win" is additional >> > > emulation features, like those introduced in MUX patch (being able to >> > > utilize signals outside of the host range). If having those features >> in >> > > QEMU warrants the additional complexity, then re-working this patch >> > > on-top of that infrastructure seems like a good idea. >> > > >> > > If the maintainers want to go down that route, then I would be happy >> to >> > > re-work this patch utilizing the infrastructure from the MUX patch. >> > > Unfortunately it will require non-trivial changes, so it may be best >> to >> > > wait until that patch is merged. I could also provide a patch "on top >> > > of" the MUX patch, if that's desired/more convenient. >> > > >> > > Just one last note, if you do decide to merge the MUX patch, then it >> > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the >> > > multiplexing signal if possible, to avoid breaking go binaries. >> > > >> > >> > Personally, I prefer a solution that breaks nothing. >> > >> > Aleksandar, Milos, >> > >> > do you have an updated version of you series "Support signal passing for >> > targets having more signals than host"? >> > >> >> Milos is unfortunetely working on an entirely different project now, and >> can't spare enough time to finish the series. I am also busy with other >> issues, even though I would like very much this or equivalent solution to >> be integrated. Alternatively, someone in the team may have time later this >> year, but I do not know that yet - perhaps somebody else (Josh) can take >> over the series? >> >> Sincerely, >> Aleksandar >> >> >> > Thanks, >> > Laurent >> > > > [-- Attachment #2: Type: text/html, Size: 10077 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-08-28 17:31 ` [Qemu-devel] [EXTERNAL]Re: " Aleksandar Markovic 2019-08-31 1:26 ` Josh Kunz via Qemu-devel @ 2019-12-07 13:05 ` Aleksandar Markovic 1 sibling, 0 replies; 15+ messages in thread From: Aleksandar Markovic @ 2019-12-07 13:05 UTC (permalink / raw) To: Aleksandar Markovic Cc: Peter Maydell, marlies.ruck, qemu-trivial, riku.voipio, Laurent Vivier, qemu-devel, Aleksandar Markovic, Josh Kunz, Petar Jovanovic, milos.stojanovic, Shu-Chun Weng [-- Attachment #1: Type: text/plain, Size: 5471 bytes --] On Wednesday, August 28, 2019, Aleksandar Markovic <amarkovic@wavecomp.com> wrote: > > From: Laurent Vivier <laurent@vivier.eu> > > Sent: Wednesday, August 28, 2019 10:51 AM > > To: Josh Kunz; Aleksandar Markovic; milos.stojanovic@rt-rk.com > > Cc: marlies.ruck@gmail.com; qemu-devel@nongnu.org; riku.voipio@iki.fi; > > qemu-trivial@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar > Markovic > > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and > SIGRTMAX - 1 > > > > Le 26/08/2019 à 23:10, Josh Kunz a écrit : > > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier <laurent@vivier.eu > > > <mailto:laurent@vivier.eu>> wrote: > > > > > > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > > > Hi all, > > > > > > > > I have also experienced issues with SIGRTMIN + 1, and am > interested in > > > > moving this patch forwards. Anything I can do here to help? > Would the > > > > maintainers prefer myself or Marli re-submit the patch? > > > > > > > > The Go issue here seems particularly sticky. Even if we update > the Go > > > > runtime, users may try and run older binaries built with older > > > versions of > > > > Go for quite some time (months? years?). Would it be better to > > > hide this > > > > behind some kind of build-time flag > > > (`--enable-sigrtmin-plus-one-proxy` or > > > > something), so that some users can opt-in, but older binaries > > > still work as > > > > expected? > > > > > > > > Also, here is a link to the original thread this message is in > > > reply to > > > > in-case my mail-client doesn't set up the reply properly: > > > > https://lists.nongnu.org/archive/html/qemu-devel/2019- > 07/msg01303.html > > > > > > The problem here is we break something to fix something else. > > > > > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > > > Support signal passing for targets having more signals than host" > [1] > > > can fix the problem in a better way? > > > > > > > > > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) > > > does not directly fix the issue addressed by this patch (re-wiring > > > SIGRTMIN+1), but since it basically implements generic signal > > > multiplexing, it could be re-worked to address this case as well. The > > > way it handles `si_code` spooks me a little bit. It could easily be > > > broken by a kernel version change, and such a breakage could be hard to > > > detect or lead to surprising results. Other than that, it looks like a > > > reasonable implementation. > > > > > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic > > > signal-multiplexing mechanism doesn't seem *that* much better to me. It > > > adds a lot of complexity, and only saves a single signal (assuming > glibc > > > doesn't add more reserved signals). The "big win" is additional > > > emulation features, like those introduced in MUX patch (being able to > > > utilize signals outside of the host range). If having those features in > > > QEMU warrants the additional complexity, then re-working this patch > > > on-top of that infrastructure seems like a good idea. > > > > > > If the maintainers want to go down that route, then I would be happy to > > > re-work this patch utilizing the infrastructure from the MUX patch. > > > Unfortunately it will require non-trivial changes, so it may be best to > > > wait until that patch is merged. I could also provide a patch "on top > > > of" the MUX patch, if that's desired/more convenient. > > > > > > Just one last note, if you do decide to merge the MUX patch, then it > > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the > > > multiplexing signal if possible, to avoid breaking go binaries. > > > > > > > Personally, I prefer a solution that breaks nothing. > > > > Aleksandar, Milos, > > > > do you have an updated version of you series "Support signal passing for > > targets having more signals than host"? > > > > Milos is unfortunetely working on an entirely different project now, and > can't spare enough time to finish the series. I am also busy with other > issues, even though I would like very much this or equivalent solution to > be integrated. Alternatively, someone in the team may have time later this > year, but I do not know that yet - perhaps somebody else (Josh) can take > over the series? > > Hello, all. From my side, status quo. Milos (who ironically works in the office next to mine) expressed interest in modifying his solution to be in accordance with what Peter said, says that this is doable, but requires a lot of meticulous work - however, he is too involved into his project for months to go. I am also involved in other things, and, furthermore, has less background knowledge than Milos. That said, we in MIPS would like the solution described by Peter as much as other platforms, if not more. All this taken into account, perhaps this can be a project for Outreachy or Google Summer of Code, mentored by Peter? The perhaps largest problem with that is that the person doing it would need some steep learning curve (on signals in general, and their treatment in QEMU), that can take some significant time. Yours, Aleksandar > Sincerely, > Aleksandar > > > > Thanks, > > Laurent > > > [-- Attachment #2: Type: text/html, Size: 7116 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 @ 2019-06-21 22:58 Marlies Ruck 2019-06-28 23:26 ` Marlies Ruck 0 siblings, 1 reply; 15+ messages in thread From: Marlies Ruck @ 2019-06-21 22:58 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 345 bytes --] Hi, Attached is a patch to let guest programs use SIGRTMIN + 1 by swapping with SIGRTMAX - 1. Since QEMU links against glibc, it reserves the signal for itself and returns EINVAL (as noted in the commit message). This means various applications that use SIGRTMIN + 1 cannot run on QEMU, including G-WAN web server and Open TFTP. Thanks, Marli [-- Attachment #2: 0001-Swap-SIGRTMIN-1-and-SIGRTMAX-1.patch --] [-- Type: application/octet-stream, Size: 1873 bytes --] From 096c244668345f80a4582799d0b860b7c20a9b59 Mon Sep 17 00:00:00 2001 From: marlies ruck <marlies@forallsecure.com> Date: Fri, 21 Jun 2019 14:42:42 -0700 Subject: [PATCH] Swap SIGRTMIN + 1 and SIGRTMAX - 1 We already have a hack whereby we flip the guest's SIGRTMAX and SIGRTMIN signals, to avoid a collision between guest use of SIGRTMIN and the host libc use of it for SIGCANCEL. However newer glibc also uses SIGRTMIN+1 for internal purposes (as SIGSETXID). Reverse SIGRTMIN+1 and SIGRTMAX-1 so the guest can successfully use SIGRTMIN+1. This didn't cause any immediately observed issues in guests because glibc does not check the return value when it registers a SIGSETXID handler(!). However it meant that if a guest program with more than one thread issued a setuid() syscall it would hang. Credit: Peter Maydell https://patches.linaro.org/patch/63313/ Signed-off-by: marlies ruck <marlies@forallsecure.com> --- linux-user/signal.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/linux-user/signal.c b/linux-user/signal.c index 5cd237834d..137a449140 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -75,8 +75,12 @@ static uint8_t host_to_target_signal_table[_NSIG] = { /* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with host libpthread signals. This assumes no one actually uses SIGRTMAX :-/ To fix this properly we need to do manual signal delivery multiplexed - over a single host signal. */ + over a single host signal. + Similarly we reverse SIGRTMIN + 1 and SIGRTMAX - 1, because + host glibc uses SIGRTMIN+1 for SIGSETXID. */ [__SIGRTMIN] = __SIGRTMAX, + [__SIGRTMIN + 1] = __SIGRTMAX - 1, + [__SIGRTMAX - 1] = __SIGRTMIN + 1, [__SIGRTMAX] = __SIGRTMIN, }; static uint8_t target_to_host_signal_table[_NSIG]; -- 2.20.1 (Apple Git-117) ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-06-21 22:58 Marlies Ruck @ 2019-06-28 23:26 ` Marlies Ruck 2019-06-29 10:53 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 15+ messages in thread From: Marlies Ruck @ 2019-06-28 23:26 UTC (permalink / raw) To: qemu-devel Hi, I just wanted to follow up since I sent this patch a week ago to make sure it was a received. An ack would be appreciated. Thanks, Marli On Fri, Jun 21, 2019 at 3:58 PM Marlies Ruck <marlies.ruck@gmail.com> wrote: > Hi, > > Attached is a patch to let guest programs use SIGRTMIN + 1 by swapping > with SIGRTMAX - 1. Since QEMU links against glibc, it reserves the signal > for itself and returns EINVAL (as noted in the commit message). This means > various applications that use SIGRTMIN + 1 cannot run on QEMU, including > G-WAN web server and Open TFTP. > > Thanks, > Marli > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-06-28 23:26 ` Marlies Ruck @ 2019-06-29 10:53 ` Philippe Mathieu-Daudé 2019-07-01 9:08 ` Peter Maydell 0 siblings, 1 reply; 15+ messages in thread From: Philippe Mathieu-Daudé @ 2019-06-29 10:53 UTC (permalink / raw) To: Marlies Ruck, qemu-devel, Riku Voipio, Laurent Vivier, Peter Maydell Hi Marlies, On 6/29/19 1:26 AM, Marlies Ruck wrote: > Hi, > > I just wanted to follow up since I sent this patch a week ago to make sure > it was a received. An ack would be appreciated. You did not Cc'ed the maintainer, so he likely missed it. See: https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer $ ./scripts/get_maintainer.pl -f linux-user/signal.c Riku Voipio <riku.voipio@iki.fi> (maintainer:Linux user) Laurent Vivier <laurent@vivier.eu> (reviewer:Linux user) BTW you should also look at the next paragraph in this wiki page: https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment Since you credit Peter Maydell, it would be kind to Cc him too. I Cc'ed Riku/Laurent/Peter for you now. Regards, Phil. > On Fri, Jun 21, 2019 at 3:58 PM Marlies Ruck <marlies.ruck@gmail.com> wrote: > >> Hi, >> >> Attached is a patch to let guest programs use SIGRTMIN + 1 by swapping >> with SIGRTMAX - 1. Since QEMU links against glibc, it reserves the signal >> for itself and returns EINVAL (as noted in the commit message). This means >> various applications that use SIGRTMIN + 1 cannot run on QEMU, including >> G-WAN web server and Open TFTP. >> >> Thanks, >> Marli >> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-06-29 10:53 ` Philippe Mathieu-Daudé @ 2019-07-01 9:08 ` Peter Maydell 2019-07-01 22:04 ` Marlies Ruck 0 siblings, 1 reply; 15+ messages in thread From: Peter Maydell @ 2019-07-01 9:08 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Marlies Ruck, Riku Voipio, QEMU Developers, Laurent Vivier On Sat, 29 Jun 2019 at 11:53, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > Hi Marlies, > > On 6/29/19 1:26 AM, Marlies Ruck wrote: > > Hi, > > > > I just wanted to follow up since I sent this patch a week ago to make sure > > it was a received. An ack would be appreciated. > > You did not Cc'ed the maintainer, so he likely missed it. > See: > https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer > > $ ./scripts/get_maintainer.pl -f linux-user/signal.c > Riku Voipio <riku.voipio@iki.fi> (maintainer:Linux user) > Laurent Vivier <laurent@vivier.eu> (reviewer:Linux user) > > BTW you should also look at the next paragraph in this wiki page: > https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment > > Since you credit Peter Maydell, it would be kind to Cc him too. I have a strong suspicion that if we applied this patch it would break running a pile of Go binaries that currently work, which means it's something we need to be cautious about. (The Go runtime special cases the fact that when it tries to register some signals they don't work, but will abort on startup I think if it can't register a handler for SIGRTMAX-1, which will be the case after this patch.) thanks -- PMM ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-07-01 9:08 ` Peter Maydell @ 2019-07-01 22:04 ` Marlies Ruck 2019-07-03 21:11 ` Marlies Ruck 0 siblings, 1 reply; 15+ messages in thread From: Marlies Ruck @ 2019-07-01 22:04 UTC (permalink / raw) To: Peter Maydell Cc: Riku Voipio, Philippe Mathieu-Daudé, QEMU Developers, Laurent Vivier Hi All, You are correct, this would break Go binaries. I was planning on submitting a PR to the Go runtime if my patch was accepted to QEMU. The Go PR would ignore the failure to register a handler for SIGRTMAX - 1, just as it currently ignores the failure on SIGRTMAX ( https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L443). Does this seem reasonable to you? My local set up has these patches to QEMU and Go and it allows me to run both Go guest programs, and guest programs that use SIGRTMIN + 1. Also, thank you Peter and Phil for your patience as this is my first time contributing to QEMU. If you decide to use this patch, I'm happy to resend the patch via `git send email`. Thanks! Marli On Mon, Jul 1, 2019 at 2:08 AM Peter Maydell <peter.maydell@linaro.org> wrote: > On Sat, 29 Jun 2019 at 11:53, Philippe Mathieu-Daudé <philmd@redhat.com> > wrote: > > > > Hi Marlies, > > > > On 6/29/19 1:26 AM, Marlies Ruck wrote: > > > Hi, > > > > > > I just wanted to follow up since I sent this patch a week ago to make > sure > > > it was a received. An ack would be appreciated. > > > > You did not Cc'ed the maintainer, so he likely missed it. > > See: > > https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer > > > > $ ./scripts/get_maintainer.pl -f linux-user/signal.c > > Riku Voipio <riku.voipio@iki.fi> (maintainer:Linux user) > > Laurent Vivier <laurent@vivier.eu> (reviewer:Linux user) > > > > BTW you should also look at the next paragraph in this wiki page: > > > https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment > > > > Since you credit Peter Maydell, it would be kind to Cc him too. > > I have a strong suspicion that if we applied this patch it would > break running a pile of Go binaries that currently work, which means > it's something we need to be cautious about. (The Go runtime special > cases the fact that when it tries to register some signals they don't > work, but will abort on startup I think if it can't register a handler > for SIGRTMAX-1, which will be the case after this patch.) > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 2019-07-01 22:04 ` Marlies Ruck @ 2019-07-03 21:11 ` Marlies Ruck 0 siblings, 0 replies; 15+ messages in thread From: Marlies Ruck @ 2019-07-03 21:11 UTC (permalink / raw) To: Peter Maydell Cc: Riku Voipio, Philippe Mathieu-Daudé, QEMU Developers, Laurent Vivier Hi, Just wanted to follow up to see what your thoughts are. Is it preferable if I submit a PR to the Go runtime first? That would mitigate concerns about Go breaking on QEMU with this patch. Thanks, Marli On Mon, Jul 1, 2019 at 3:04 PM Marlies Ruck <marlies.ruck@gmail.com> wrote: > Hi All, > > You are correct, this would break Go binaries. I was planning on > submitting a PR to the Go runtime if my patch was accepted to QEMU. The Go > PR would ignore the failure to register a handler for SIGRTMAX - 1, just as > it currently ignores the failure on SIGRTMAX ( > https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L443). > Does this seem reasonable to you? My local set up has these patches to > QEMU and Go and it allows me to run both Go guest programs, and guest > programs that use SIGRTMIN + 1. > > Also, thank you Peter and Phil for your patience as this is my first time > contributing to QEMU. If you decide to use this patch, I'm happy to resend > the patch via `git send email`. > > Thanks! > Marli > > > > On Mon, Jul 1, 2019 at 2:08 AM Peter Maydell <peter.maydell@linaro.org> > wrote: > >> On Sat, 29 Jun 2019 at 11:53, Philippe Mathieu-Daudé <philmd@redhat.com> >> wrote: >> > >> > Hi Marlies, >> > >> > On 6/29/19 1:26 AM, Marlies Ruck wrote: >> > > Hi, >> > > >> > > I just wanted to follow up since I sent this patch a week ago to make >> sure >> > > it was a received. An ack would be appreciated. >> > >> > You did not Cc'ed the maintainer, so he likely missed it. >> > See: >> > >> https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer >> > >> > $ ./scripts/get_maintainer.pl -f linux-user/signal.c >> > Riku Voipio <riku.voipio@iki.fi> (maintainer:Linux user) >> > Laurent Vivier <laurent@vivier.eu> (reviewer:Linux user) >> > >> > BTW you should also look at the next paragraph in this wiki page: >> > >> https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment >> > >> > Since you credit Peter Maydell, it would be kind to Cc him too. >> >> I have a strong suspicion that if we applied this patch it would >> break running a pile of Go binaries that currently work, which means >> it's something we need to be cautious about. (The Go runtime special >> cases the fact that when it tries to register some signals they don't >> work, but will abort on startup I think if it can't register a handler >> for SIGRTMAX-1, which will be the case after this patch.) >> >> thanks >> -- PMM >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-12-07 16:58 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-19 21:46 [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1 Josh Kunz via Qemu-devel 2019-08-21 9:28 ` Laurent Vivier 2019-08-26 21:10 ` Josh Kunz via Qemu-devel 2019-08-27 8:08 ` Peter Maydell 2019-08-28 8:51 ` Laurent Vivier 2019-08-28 17:31 ` [Qemu-devel] [EXTERNAL]Re: " Aleksandar Markovic 2019-08-31 1:26 ` Josh Kunz via Qemu-devel 2019-10-02 18:06 ` [EXTERNAL]Re: [Qemu-devel] " Josh Kunz 2019-12-07 13:05 ` Aleksandar Markovic -- strict thread matches above, loose matches on Subject: below -- 2019-06-21 22:58 Marlies Ruck 2019-06-28 23:26 ` Marlies Ruck 2019-06-29 10:53 ` Philippe Mathieu-Daudé 2019-07-01 9:08 ` Peter Maydell 2019-07-01 22:04 ` Marlies Ruck 2019-07-03 21:11 ` Marlies Ruck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).