* [PATCH] meson: remove -no-pie linker flag
@ 2023-05-22 8:08 Paolo Bonzini
2023-05-22 8:19 ` Philippe Mathieu-Daudé
` (4 more replies)
0 siblings, 5 replies; 12+ messages in thread
From: Paolo Bonzini @ 2023-05-22 8:08 UTC (permalink / raw)
To: qemu-devel; +Cc: vr_qemu, marcandre.lureau
The large comment in the patch says it all; the -no-pie flag is broken and
this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
("build: move remaining compiler flag tests to meson", 2023-05-18).
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
meson.build | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/meson.build b/meson.build
index 0a5cdefd4d3d..6733b2917081 100644
--- a/meson.build
+++ b/meson.build
@@ -267,10 +267,15 @@ endif
# has explicitly disabled PIE we need to extend our cflags.
if not get_option('b_pie')
qemu_common_flags += cc.get_supported_arguments('-fno-pie')
- if not get_option('prefer_static')
- # No PIE is implied by -static which we added above.
- qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
- endif
+ # What about linker flags? For a static build, no PIE is implied by -static
+ # which we added above. For dynamic linking, adding -no-pie is messy because
+ # it overrides -shared: the linker then wants to build an executable instead
+ # of a shared library and the build fails. Before moving this code to Meson,
+ # we went through a dozen different commits affecting the usage of -no-pie,
+ # ultimately settling for a completely broken one that added -no-pie to the
+ # compiler flags together with -fno-pie... except that -no-pie is a linker
+ # flag that has no effect on the compiler command line. So, don't add
+ # -no-pie anywhere and cross fingers.
endif
if not get_option('stack_protector').disabled()
--
2.40.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 8:08 [PATCH] meson: remove -no-pie linker flag Paolo Bonzini
@ 2023-05-22 8:19 ` Philippe Mathieu-Daudé
2023-05-22 14:39 ` Richard Henderson
` (3 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Philippe Mathieu-Daudé @ 2023-05-22 8:19 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel; +Cc: vr_qemu, marcandre.lureau
On 22/5/23 10:08, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line. So, don't add
> + # -no-pie anywhere and cross fingers.
> endif
>
> if not get_option('stack_protector').disabled()
This removes this annoying warning with Clang on Aarch64:
clang: warning: argument unused during compilation: '-no-pie'
[-Wunused-command-line-argument]
Not tested on mingw64, but at least on Darwin:
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 8:08 [PATCH] meson: remove -no-pie linker flag Paolo Bonzini
2023-05-22 8:19 ` Philippe Mathieu-Daudé
@ 2023-05-22 14:39 ` Richard Henderson
2023-05-23 7:23 ` Paolo Bonzini
2023-05-22 15:54 ` Richard Henderson
` (2 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2023-05-22 14:39 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel; +Cc: vr_qemu, marcandre.lureau
On 5/22/23 01:08, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above.
Is it though? That was the major problem at the time: it wasn't.
IIRC, debian has enabled link-pie-by-default, so '-static' meant '-static-pie'. Moreover,
not all of their static libraries were built -fpie, which led to link errors.
Trying both now, e.g. '--static --disable-system --disable-tools --disable-docs',
a link line contains
... -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa ...
^^^^
Where does that come from, and why isn't -no-pie the antidote?
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 8:08 [PATCH] meson: remove -no-pie linker flag Paolo Bonzini
2023-05-22 8:19 ` Philippe Mathieu-Daudé
2023-05-22 14:39 ` Richard Henderson
@ 2023-05-22 15:54 ` Richard Henderson
2023-05-23 7:52 ` Michael Tokarev
2023-05-23 5:57 ` Volker Rümelin
2023-05-23 8:00 ` Daniel P. Berrangé
4 siblings, 1 reply; 12+ messages in thread
From: Richard Henderson @ 2023-05-22 15:54 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel; +Cc: vr_qemu, marcandre.lureau
On 5/22/23 01:08, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
It's not nearly as simple as that.
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line.
-no-pie is a linker flag, but distro folk that didn't quite know what they were doing made
local changes to gcc's specs file. So it *is* a compiler command-line flag, but only for
some builds of gcc.
We can't just remove -no-pie, we need to probe for it as cc.get_supported_arguments
instead of cc.get_supported_link_arguments.
Or something. It's a mess, for sure.
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 8:08 [PATCH] meson: remove -no-pie linker flag Paolo Bonzini
` (2 preceding siblings ...)
2023-05-22 15:54 ` Richard Henderson
@ 2023-05-23 5:57 ` Volker Rümelin
2023-05-23 8:00 ` Daniel P. Berrangé
4 siblings, 0 replies; 12+ messages in thread
From: Volker Rümelin @ 2023-05-23 5:57 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel; +Cc: marcandre.lureau
Am 22.05.23 um 10:08 schrieb Paolo Bonzini:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line. So, don't add
> + # -no-pie anywhere and cross fingers.
> endif
>
> if not get_option('stack_protector').disabled()
QEMU builds again on Windows with MSYS2 mingw64.
I also tried to build QEMU on Windows with libslirp from the subproject
folder. The issue reported in
https://gitlab.com/qemu-project/qemu/-/issues/1664 is fixed, but it now
fails with a different error. This is a libslirp bug. See
https://gitlab.freedesktop.org/slirp/libslirp/-/issues/68. The revision
in subprojects/slirp.wrap should be at least
fc5eaaf6f68d5cff76468c63984c33c4fb51506d.
Building QEMU on my Linux system works fine.
Tested-by: Volker Rümelin <vr_qemu@t-online.de>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 14:39 ` Richard Henderson
@ 2023-05-23 7:23 ` Paolo Bonzini
0 siblings, 0 replies; 12+ messages in thread
From: Paolo Bonzini @ 2023-05-23 7:23 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel, vr_qemu, marcandre.lureau
On Mon, May 22, 2023 at 4:39 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
> > + # What about linker flags? For a static build, no PIE is implied by -static
> > + # which we added above.
>
> Is it though? That was the major problem at the time: it wasn't.
It's what configure was doing:
if test "$static" = "yes"; then
if test "$pie" != "no" && compile_prog "-Werror -fPIE -DPIE"
"-static-pie"; then
CONFIGURE_CFLAGS="-fPIE -DPIE $CONFIGURE_CFLAGS"
pie="yes"
elif test "$pie" = "yes"; then
error_exit "-static-pie not available due to missing toolchain support"
else
pie="no"
QEMU_CFLAGS="-fno-pie $QEMU_CFLAGS"
fi
elif test "$pie" = "no"; then
if compile_prog "-Werror -fno-pie" "-no-pie"; then
CONFIGURE_CFLAGS="-fno-pie $CONFIGURE_CFLAGS"
CONFIGURE_LDFLAGS="-no-pie $CONFIGURE_LDFLAGS"
QEMU_CFLAGS="-fno-pie -no-pie $QEMU_CFLAGS"
fi
fi
Note that the code to use -no-pie is only used if test "$static" = no.
> Trying both now, e.g. '--static --disable-system --disable-tools --disable-docs',
> a link line contains
>
> ... -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa ...
> ^^^^
>
> Where does that come from, and why isn't -no-pie the antidote?
That comes from Meson's -Db_pie=true, but it is followed by
-static-pie later in the command line so all is good.
In other words, whatever we add second in the command line wins and
that is good for executables; but it is a problem when -no-pie
overrides -shared, thus messing up compilation of any shared library.
Paolo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 15:54 ` Richard Henderson
@ 2023-05-23 7:52 ` Michael Tokarev
0 siblings, 0 replies; 12+ messages in thread
From: Michael Tokarev @ 2023-05-23 7:52 UTC (permalink / raw)
To: Richard Henderson, Paolo Bonzini, qemu-devel; +Cc: vr_qemu, marcandre.lureau
22.05.2023 18:54, Richard Henderson wrote:
..
> -no-pie is a linker flag, but distro folk that didn't quite know what they were doing made local changes to gcc's specs file. So it *is* a compiler
> command-line flag, but only for some builds of gcc.
Which distros is that? Debian?
Patching gcc spec file like this - if that's true - is a way to disaster,
and should be stopped.
Thanks,
/mjt
> We can't just remove -no-pie, we need to probe for it as cc.get_supported_arguments instead of cc.get_supported_link_arguments.
>
> Or something. It's a mess, for sure.
>
>
> r~
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-22 8:08 [PATCH] meson: remove -no-pie linker flag Paolo Bonzini
` (3 preceding siblings ...)
2023-05-23 5:57 ` Volker Rümelin
@ 2023-05-23 8:00 ` Daniel P. Berrangé
2023-05-23 8:02 ` Paolo Bonzini
4 siblings, 1 reply; 12+ messages in thread
From: Daniel P. Berrangé @ 2023-05-23 8:00 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel, vr_qemu, marcandre.lureau
On Mon, May 22, 2023 at 10:08:16AM +0200, Paolo Bonzini wrote:
> The large comment in the patch says it all; the -no-pie flag is broken and
> this is why it was not included in QEMU_LDFLAGS before commit a988b4c5614
> ("build: move remaining compiler flag tests to meson", 2023-05-18).
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1664
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> meson.build | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0a5cdefd4d3d..6733b2917081 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -267,10 +267,15 @@ endif
> # has explicitly disabled PIE we need to extend our cflags.
> if not get_option('b_pie')
> qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> - if not get_option('prefer_static')
> - # No PIE is implied by -static which we added above.
> - qemu_ldflags += cc.get_supported_link_arguments('-no-pie')
> - endif
> + # What about linker flags? For a static build, no PIE is implied by -static
> + # which we added above. For dynamic linking, adding -no-pie is messy because
> + # it overrides -shared: the linker then wants to build an executable instead
> + # of a shared library and the build fails. Before moving this code to Meson,
> + # we went through a dozen different commits affecting the usage of -no-pie,
> + # ultimately settling for a completely broken one that added -no-pie to the
> + # compiler flags together with -fno-pie... except that -no-pie is a linker
> + # flag that has no effect on the compiler command line. So, don't add
> + # -no-pie anywhere and cross fingers.
> endif
I'm curious why we need to do anything ? I would have thought that meson
should handle 'b_pie' itself, passing the right args to $CC that it feels
are appropriate. I don't recall seeing other apps using meson trying to
handle b_pie logic - what's special about QEMU ? IOW, is it possible to
delete this entire b_pie condition and thus avoid worrying about this
problem ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-23 8:00 ` Daniel P. Berrangé
@ 2023-05-23 8:02 ` Paolo Bonzini
2023-05-23 8:18 ` Daniel P. Berrangé
0 siblings, 1 reply; 12+ messages in thread
From: Paolo Bonzini @ 2023-05-23 8:02 UTC (permalink / raw)
To: Daniel P. Berrangé; +Cc: qemu-devel, vr_qemu, marcandre.lureau
On Tue, May 23, 2023 at 10:00 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> I'm curious why we need to do anything ? I would have thought that meson
> should handle 'b_pie' itself, passing the right args to $CC that it feels
> are appropriate. I don't recall seeing other apps using meson trying to
> handle b_pie logic - what's special about QEMU ? IOW, is it possible to
> delete this entire b_pie condition and thus avoid worrying about this
> problem ?
The issue is that Meson only has "enable PIE" or "leave PIE to the
compiler default", while QEMU also has "disable PIE"---which is the
messy one.
Paolo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-23 8:02 ` Paolo Bonzini
@ 2023-05-23 8:18 ` Daniel P. Berrangé
2023-05-23 11:55 ` Paolo Bonzini
2023-05-23 13:14 ` Richard Henderson
0 siblings, 2 replies; 12+ messages in thread
From: Daniel P. Berrangé @ 2023-05-23 8:18 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel, vr_qemu, marcandre.lureau
On Tue, May 23, 2023 at 10:02:51AM +0200, Paolo Bonzini wrote:
> On Tue, May 23, 2023 at 10:00 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > I'm curious why we need to do anything ? I would have thought that meson
> > should handle 'b_pie' itself, passing the right args to $CC that it feels
> > are appropriate. I don't recall seeing other apps using meson trying to
> > handle b_pie logic - what's special about QEMU ? IOW, is it possible to
> > delete this entire b_pie condition and thus avoid worrying about this
> > problem ?
>
> The issue is that Meson only has "enable PIE" or "leave PIE to the
> compiler default", while QEMU also has "disable PIE"---which is the
> messy one.
Does QEMU actually need "disable PIE" ? It existed in configure of
course, is there a reason we need to continue to support it in meson ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-23 8:18 ` Daniel P. Berrangé
@ 2023-05-23 11:55 ` Paolo Bonzini
2023-05-23 13:14 ` Richard Henderson
1 sibling, 0 replies; 12+ messages in thread
From: Paolo Bonzini @ 2023-05-23 11:55 UTC (permalink / raw)
To: Daniel P. Berrangé; +Cc: qemu-devel, vr_qemu, marcandre.lureau
On Tue, May 23, 2023 at 10:18 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > The issue is that Meson only has "enable PIE" or "leave PIE to the
> > compiler default", while QEMU also has "disable PIE"---which is the
> > messy one.
>
> Does QEMU actually need "disable PIE" ? It existed in configure of
> course, is there a reason we need to continue to support it in meson ?
We have "disable PIE" support because PIE has a performance cost,
though that's mostly for 32-bit x86 processors. Other ISAs have
instructions that help (like x86-64's RIP-relative addressing,
aarch64's adr/adrp, or RISC-V's auipc) and then position-independent
code becomes the natural one anyway.
However, I am inclined to keep it also because "--disable-pie uses the
compiler default, and who knows what your distro did" is less obvious
than "--disable-pie disables PIE".
Paolo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] meson: remove -no-pie linker flag
2023-05-23 8:18 ` Daniel P. Berrangé
2023-05-23 11:55 ` Paolo Bonzini
@ 2023-05-23 13:14 ` Richard Henderson
1 sibling, 0 replies; 12+ messages in thread
From: Richard Henderson @ 2023-05-23 13:14 UTC (permalink / raw)
To: Daniel P. Berrangé, Paolo Bonzini
Cc: qemu-devel, vr_qemu, marcandre.lureau
On 5/23/23 01:18, Daniel P. Berrangé wrote:
> On Tue, May 23, 2023 at 10:02:51AM +0200, Paolo Bonzini wrote:
>> On Tue, May 23, 2023 at 10:00 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> I'm curious why we need to do anything ? I would have thought that meson
>>> should handle 'b_pie' itself, passing the right args to $CC that it feels
>>> are appropriate. I don't recall seeing other apps using meson trying to
>>> handle b_pie logic - what's special about QEMU ? IOW, is it possible to
>>> delete this entire b_pie condition and thus avoid worrying about this
>>> problem ?
>>
>> The issue is that Meson only has "enable PIE" or "leave PIE to the
>> compiler default", while QEMU also has "disable PIE"---which is the
>> messy one.
>
> Does QEMU actually need "disable PIE" ? It existed in configure of
> course, is there a reason we need to continue to support it in meson ?
We need it for aarch64 runner, because the OS built glibc static libraries with -fpie
instead of -fPIE, and we get a relocation overflow at link time.
Upstream glibc has been fixed, but there has been no update to ubuntu packages.
r~
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-05-23 13:15 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-05-22 8:08 [PATCH] meson: remove -no-pie linker flag Paolo Bonzini
2023-05-22 8:19 ` Philippe Mathieu-Daudé
2023-05-22 14:39 ` Richard Henderson
2023-05-23 7:23 ` Paolo Bonzini
2023-05-22 15:54 ` Richard Henderson
2023-05-23 7:52 ` Michael Tokarev
2023-05-23 5:57 ` Volker Rümelin
2023-05-23 8:00 ` Daniel P. Berrangé
2023-05-23 8:02 ` Paolo Bonzini
2023-05-23 8:18 ` Daniel P. Berrangé
2023-05-23 11:55 ` Paolo Bonzini
2023-05-23 13:14 ` Richard Henderson
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).