Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 4/20/2022 6:13 AM, Thomas Huth wrote: On 19/04/2022 18.24, Daniel P. Berrangé wrote: On Mon, Apr 11, 2022 at 08:55:19AM +0200, Thomas Huth wrote: On 11/04/2022 01.50, Brad Smith wrote: On 4/10/2022 5:06 AM, Peter Maydell wrote: On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: On 4/8/2022 12:47 PM, Thomas Huth wrote: QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required. I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens. How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMM They would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I have not looked at the CI bits to see how difficult that would be. Our release cycles are 6 months and the next release will be in the middle of October. OK, thanks for the update, Brad ... so I guess we should defer this patch to QEMU 7.2 (to be released in december) instead? (which would be fine for me - I just wanted to get the discussion started, that's also why I've marked this patch as RFC) Perhaps make 7.1 simply issue a warning message in configure if the bundled slirp is used, to give people a heads up that they'll want to install libslirp-devel soon. Not sure if people will notice a warning in the output of "configure" ... but I've put some sentences in the ChangeLog here: https://wiki.qemu.org/ChangeLog/7.0#New_deprecated_options_and_features (which we could repeat for the 7.1 release again) I hope that helps to make people aware... Thomas Just to note.. my libslirp port went in. https://marc.info/?l=openbsd-ports-cvs=165070969206193=2 and have switched our QEMU port to build with the libslirp port.. https://marc.info/?l=openbsd-ports-cvs=165070979906266=2
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 19/04/2022 18.24, Daniel P. Berrangé wrote: On Mon, Apr 11, 2022 at 08:55:19AM +0200, Thomas Huth wrote: On 11/04/2022 01.50, Brad Smith wrote: On 4/10/2022 5:06 AM, Peter Maydell wrote: On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: On 4/8/2022 12:47 PM, Thomas Huth wrote: QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required. I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens. How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMM They would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I have not looked at the CI bits to see how difficult that would be. Our release cycles are 6 months and the next release will be in the middle of October. OK, thanks for the update, Brad ... so I guess we should defer this patch to QEMU 7.2 (to be released in december) instead? (which would be fine for me - I just wanted to get the discussion started, that's also why I've marked this patch as RFC) Perhaps make 7.1 simply issue a warning message in configure if the bundled slirp is used, to give people a heads up that they'll want to install libslirp-devel soon. Not sure if people will notice a warning in the output of "configure" ... but I've put some sentences in the ChangeLog here: https://wiki.qemu.org/ChangeLog/7.0#New_deprecated_options_and_features (which we could repeat for the 7.1 release again) I hope that helps to make people aware... Thomas
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On Mon, Apr 11, 2022 at 08:55:19AM +0200, Thomas Huth wrote: > On 11/04/2022 01.50, Brad Smith wrote: > > On 4/10/2022 5:06 AM, Peter Maydell wrote: > > > On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: > > > > On 4/8/2022 12:47 PM, Thomas Huth wrote: > > > > > QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important > > > > > distro that did not have a pre-packaged libslirp has been dismissed. > > > > > All other major distros seem to have a libslirp package in their > > > > > distribution already - according to repology.org: > > > > > > > > > > Fedora 34: 4.4.0 > > > > > CentOS 8 (RHEL-8): 4.4.0 > > > > > Debian Buster: 4.3.1 (in buster-backports) > > > > > OpenSUSE Leap 15.3: 4.3.1 > > > > > Ubuntu LTS 20.04: 4.1.0 > > > > > FreeBSD Ports: 4.6.1 > > > > > NetBSD pkgsrc: 4.3.1 > > > > > Homebrew: 4.6.1 > > > > > MSYS2 mingw: 4.6.1 > > > > > > > > > > The only one that still seems to be missing a libslirp package is > > > > > OpenBSD - but I assume that they can add it to their ports system > > > > > quickly if required. > > > > I wish I had seen this earlier as our 7.1 release was just tagged. > > > > > > > > I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I > > > > will > > > > see about submitting it in a number of days when the tree opens. > > > How awkward would it be for an end-user who's on OpenBSD 7.1 to > > > build a QEMU that doesn't have libslirp? (That is, is it easy > > > and common for an end user to pull in a port of libslirp that only > > > came along in a later OpenBSD, or would they instead have to > > > manually compile libslirp themselves from the upstream sources?) > > > > > > (I'm asking here because if it's painful, then we should perhaps > > > defer dropping our submodule copy of libslirp a little longer.) > > > > > > thanks > > > -- PMM > > > > They would have to pull down a -current ports tree and build it. No package > > would exist for the release. It is possible, but not "supported". I have > > not looked > > at the CI bits to see how difficult that would be. > > > > Our release cycles are 6 months and the next release will be in the middle > > of October. > > OK, thanks for the update, Brad ... so I guess we should defer this patch to > QEMU 7.2 (to be released in december) instead? > (which would be fine for me - I just wanted to get the discussion started, > that's also why I've marked this patch as RFC) Perhaps make 7.1 simply issue a warning message in configure if the bundled slirp is used, to give people a heads up that they'll want to install libslirp-devel soon. We don't need to follow the formal deprecations process for build deps. Just feels like a nice thing todo if we postpone till 7.2 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 :|
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 4/11/2022 2:55 AM, Thomas Huth wrote: On 11/04/2022 01.50, Brad Smith wrote: On 4/10/2022 5:06 AM, Peter Maydell wrote: On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: On 4/8/2022 12:47 PM, Thomas Huth wrote: QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required. I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens. How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMM They would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I have not looked at the CI bits to see how difficult that would be. Our release cycles are 6 months and the next release will be in the middle of October. OK, thanks for the update, Brad ... so I guess we should defer this patch to QEMU 7.2 (to be released in december) instead? (which would be fine for me - I just wanted to get the discussion started, that's also why I've marked this patch as RFC) I would prefer that. My libslirp port will be going in in the next couple days and packages for -current snaps will be built. Our 7.2 release should be out well before the next QEMU release.
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 4/11/22 09:11, Paolo Bonzini wrote:
On 4/8/22 18:47, Thomas Huth wrote:
The only one that still seems to be missing a libslirp package is
OpenBSD - but I assume that they can add it to their ports system
quickly if required.
So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.
Signed-off-by: Thomas Huth
I would like to have feature parity even with CFI. I had written the
libslirp side a few months ago, but never tested it because I didn't get
to the QEMU side.
I updated it and you can find it at
https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/117. I'll
get to the QEMU side now.
Also, doing this at the same time as a switch to Meson >=0.60 (probably
0.61.x) would allow something like
option('slirp', type: 'feature', value: 'auto',
description: 'libslirp user mode network backend support',
deprecated: {'system': 'enabled', 'internal': 'auto'})
This keeps incremental builds working. All of this should be doable in
7.1, so this is not an objection to removing the submodule in 7.1.
Paolo
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 4/8/22 18:47, Thomas Huth wrote:
The only one that still seems to be missing a libslirp package is
OpenBSD - but I assume that they can add it to their ports system
quickly if required.
So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.
Signed-off-by: Thomas Huth
I would like to have feature parity even with CFI. I had written the
libslirp side a few months ago, but never tested it because I didn't get
to the QEMU side.
I updated it and you can find it at
https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/117.
I'll get to the QEMU side now.
Paolo
---
configure | 22 +--
meson.build | 112 +-
.gitlab-ci.d/buildtest.yml| 19 +++---
.gitmodules | 3 -
MAINTAINERS | 1 -
meson_options.txt | 5 +-
scripts/archive-source.sh | 2 +-
scripts/meson-buildoptions.sh | 4 +-
slirp | 1 -
9 files changed, 29 insertions(+), 140 deletions(-)
delete mode 16 slirp
diff --git a/configure b/configure
index 7c08c18358..3aedff78a9 100755
--- a/configure
+++ b/configure
@@ -339,10 +339,8 @@ skip_meson=no
# 1. Track which submodules are needed
if test "$default_feature" = no ; then
capstone="disabled"
- slirp="disabled"
else
capstone="auto"
- slirp="auto"
fi
fdt="auto"
@@ -874,14 +872,6 @@ for opt do
;;
--disable-tsan) tsan="no"
;;
- --disable-slirp) slirp="disabled"
- ;;
- --enable-slirp) slirp="enabled"
- ;;
- --enable-slirp=git) slirp="internal"
- ;;
- --enable-slirp=*) slirp="$optarg"
- ;;
--disable-xen) xen="disabled"
;;
--enable-xen) xen="enabled"
@@ -2576,16 +2566,6 @@ EOF
fi
fi
-##
-# check for slirp
-
-case "$slirp" in
- auto | enabled | internal)
-# Simpler to always update submodule, even if not needed.
-git_submodules="${git_submodules} slirp"
-;;
-esac
-
##
# check for usable __NR_keyctl syscall
@@ -3169,7 +3149,7 @@ if test "$skip_meson" = no; then
-Db_pie=$(if test "$pie" = yes; then echo true; else echo false; fi) \
-Db_coverage=$(if test "$gcov" = yes; then echo true; else echo
false; fi) \
-Db_lto=$lto -Dcfi=$cfi -Dtcg=$tcg -Dxen=$xen \
--Dcapstone=$capstone -Dfdt=$fdt -Dslirp=$slirp \
+-Dcapstone=$capstone -Dfdt=$fdt \
$(test -n "${LIB_FUZZING_ENGINE+xxx}" && echo
"-Dfuzzing_engine=$LIB_FUZZING_ENGINE") \
$(if test "$default_feature" = no; then echo
"-Dauto_features=disabled"; fi) \
"$@" $cross_arg "$PWD" "$source_path"
diff --git a/meson.build b/meson.build
index 861de93c4f..5d93030da5 100644
--- a/meson.build
+++ b/meson.build
@@ -560,6 +560,20 @@ else
method: 'pkg-config', kwargs: static_kwargs)
endif
+slirp = not_found
+if not get_option('slirp').auto() or have_system
+ slirp = dependency('slirp', required: get_option('slirp'),
+ method: 'pkg-config', kwargs: static_kwargs)
+ # We cannot compile QEMU with CFI and libslirp enabled at the same time.
+ # This is because we register slirp functions as callbacks for QEMU Timers.
+ # When using a system-wide shared libslirp, the type information for the
+ # callback is missing and the timer call produces a false positive with CFI.
+ if get_option('cfi')
+error('Control-Flow Integrity is not compatible with libslirp.' \
+ + ' Please configure with --disable-slirp')
+ endif
+endif
+
vde = not_found
if not get_option('vde').auto() or have_system or have_tools
vde = cc.find_library('vdeplug', has_headers: ['libvdeplug.h'],
@@ -2406,100 +2420,6 @@ if capstone_opt == 'internal'
include_directories:
'capstone/include/capstone')
endif
-slirp = not_found
-slirp_opt = 'disabled'
-if have_system
- slirp_opt = get_option('slirp')
- if slirp_opt in ['enabled', 'auto', 'system']
-have_internal = fs.exists(meson.current_source_dir() / 'slirp/meson.build')
-slirp = dependency('slirp', kwargs: static_kwargs,
- method: 'pkg-config',
- required: slirp_opt == 'system' or
- slirp_opt == 'enabled' and not have_internal)
-if slirp.found()
- slirp_opt = 'system'
-elif have_internal
- slirp_opt = 'internal'
-else
- slirp_opt = 'disabled'
-endif
- endif
- if slirp_opt == 'internal'
-slirp_deps = []
-if targetos == 'windows'
- slirp_deps = cc.find_library('iphlpapi')
-elif targetos == 'darwin'
- slirp_deps = cc.find_library('resolv')
-endif
-slirp_conf = configuration_data()
-slirp_conf.set('SLIRP_MAJOR_VERSION',
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 11/04/2022 01.50, Brad Smith wrote: On 4/10/2022 5:06 AM, Peter Maydell wrote: On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: On 4/8/2022 12:47 PM, Thomas Huth wrote: QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required. I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens. How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMM They would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I have not looked at the CI bits to see how difficult that would be. Our release cycles are 6 months and the next release will be in the middle of October. OK, thanks for the update, Brad ... so I guess we should defer this patch to QEMU 7.2 (to be released in december) instead? (which would be fine for me - I just wanted to get the discussion started, that's also why I've marked this patch as RFC) Thomas
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 4/10/2022 5:06 AM, Peter Maydell wrote: On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: On 4/8/2022 12:47 PM, Thomas Huth wrote: QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required. I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens. How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMM They would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I have not looked at the CI bits to see how difficult that would be. Our release cycles are 6 months and the next release will be in the middle of October.
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On Sun, 10 Apr 2022 at 05:51, Brad Smith wrote: > > On 4/8/2022 12:47 PM, Thomas Huth wrote: > > QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important > > distro that did not have a pre-packaged libslirp has been dismissed. > > All other major distros seem to have a libslirp package in their > > distribution already - according to repology.org: > > > >Fedora 34: 4.4.0 > >CentOS 8 (RHEL-8): 4.4.0 > >Debian Buster: 4.3.1 (in buster-backports) > > OpenSUSE Leap 15.3: 4.3.1 > > Ubuntu LTS 20.04: 4.1.0 > >FreeBSD Ports: 4.6.1 > >NetBSD pkgsrc: 4.3.1 > > Homebrew: 4.6.1 > > MSYS2 mingw: 4.6.1 > > > > The only one that still seems to be missing a libslirp package is > > OpenBSD - but I assume that they can add it to their ports system > > quickly if required. > I wish I had seen this earlier as our 7.1 release was just tagged. > > I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I > will > see about submitting it in a number of days when the tree opens. How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMM
Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp)
On 4/8/2022 12:47 PM, Thomas Huth wrote: QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed. All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required. So there is no real urgent need for keeping the slirp submodule in the QEMU tree anymore. Thus let's drop the slirp submodule now and rely on the libslirp packages from the distributions instead. Signed-off-by: Thomas Huth I wish I had seen this earlier as our 7.1 release was just tagged. I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. I will see about submitting it in a number of days when the tree opens.
