similar to: [PATCH] launch: direct: Stop using deprecated -no-kvm-pit-reinjection if qemu is new enough (RHBZ#1053847).

Introduce a new struct version with few helper functions for it: this allows to "atomically" represent a version number, without different variables to be used and checked together. Add a initialization function from a libvirt-style version number, and apply it for the qemu and libvirt versions in the direct and libvirt backends. --- src/Makefile.am | 1 +

On qemu 1.1.2: qemu-system-x86_64: -no-kvm-pit-reinjection: invalid option Thanks: josv @ IRC --- lib/launch-direct.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index efedf92..db9b9f3 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -414,10 +414,7 @@ launch_direct (guestfs_h *g, void *datav, const char *arg)

On Tue, May 17, 2016 at 03:41:10PM +0200, Pino Toscano wrote: > +extern bool guestfs_int_version_is (const struct version *v, int maj, int min, int mic); I think calling this function "is" is a bit misleading. I think we should have _ge and _le functions (cf my patch). This comparison for example is wrong: > /* qemu 1.1 claims to support virtio-scsi but in reality it's

From: "Richard W.M. Jones" <rjones@redhat.com> AAVMF is an open source UEFI implementation for aarch64 based on OVMF. As aarch64 is heading for requiring UEFI even inside guests, if the AAVMF firmware is installed on the host, use it as a hint that we should boot the guest using AAVMF instead of the default "empty machine". Note this requires very recent AAVMF, libvirt,

virtio-scsi has been supported in qemu since 2012, and it is superior in every respect to virtio-blk. There's no reason to still be using virtio-blk. virtio-scsi support was initially added in 2012 (commit 0c0a7d0d868d153adf0600189f771459e1068b0a). You can still use virtio-blk using the (deprecated) iface parameter, but don't do that in new code. --- lib/guestfs-internal.h | 1 -

Allow the appliance / root filesystem to be placed on a virtual NVDIMM and accessed directly by the guest kernel (DAX). This requires corresponding changes in supermin. --- src/guestfs-internal.h | 1 + src/launch-direct.c | 68 ++++++++++++++++++++++++++++++++++++++++---------- src/launch.c | 8 +++++- 3 files changed, 63 insertions(+), 14 deletions(-) diff --git

On Tuesday 17 May 2016 15:45:42 Richard W.M. Jones wrote: > On Tue, May 17, 2016 at 03:41:10PM +0200, Pino Toscano wrote: > > +extern bool guestfs_int_version_is (const struct version *v, int maj, int min, int mic); > > I think calling this function "is" is a bit misleading. I think > we should have _ge and _le functions (cf my patch). Makes sense, renamed to _ge.

Previously we used (on arm): -M virt -machine accel=... After this change, we use: -machine virt,accel=... On x86 there is no change. The -M option is an abbreviation for -machine, and we can combine the two options together. (Qemu combines the two options internally, but it's more predictable if we do it ourselves). Upstream qemu has supported the -machine option for over 5 years, and in

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

Hi guys, During the last few weeks, I've been looking at how to use SPDK as QEMU's bootable rootfs disk. I managed to boot up a SPDK rootfs disk by using OVMF UEFI boot-loader. And in order to deploy the guest OS before start-up(which has a unrecognizable filesystem to the host), I have written a small patch for the libguestfs. It was based on Redhat's CentOS libguestfs-1.36.10 RPM,

Dr. David Gilbert pointed out to me that the first line of the qemu -help output includes the qemu version, so we don't need to run qemu -version at all. This saves about 0.04s on the launch time when using the direct backend. --- src/launch-direct.c | 54 +++++++++++++++++++---------------------------------- 1 file changed, 19 insertions(+), 35 deletions(-) diff --git a/src/launch-direct.c

We're never going to use virtio-console since, although it is faster, it's not available during early boot, and that is more important for debugging. --- src/launch-direct.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index a81d4b3..f1fe92b 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -574,19 +574,9 @@

We're never going to use virtio-console since, although it is faster, it's not available during early boot, and that is more important for debugging. --- src/launch-direct.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index a81d4b3..e8450e1 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -574,19

--- src/launch-direct.c | 11 +++++++++++ src/launch-libvirt.c | 14 ++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/src/launch-direct.c b/src/launch-direct.c index d0af04d..52badc2 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -451,6 +451,17 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) ADD_CMDLINE ("-initrd"); ADD_CMDLINE (initrd);

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8

From: "Richard W.M. Jones" <rjones@redhat.com> --- src/launch-direct.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/launch-direct.c b/src/launch-direct.c index f06bb23..58e4b1a 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -328,6 +328,13 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) ADD_CMDLINE (VIRTIO_BLK

Instead of forcing valgrind to be run when --enable-valgrind-daemon is passed to configure, enable it only when the backend setting "valgrind_daemon" is set. This allows developers to keep building with --enable-valgrind-daemon, which unconditionally adds valgrind in the appliance but using only when requested. When --enable-valgrind-daemon is not passed (typical for release builds),

Hi, this adds an helper version struct, and uses it in the backends (for the libvirt and qemu versions) and inspection code. This also moves common code to that, so it is not repeated in many places. This should help with the small refactoring proposed with https://www.redhat.com/archives/libguestfs/2016-May/msg00070.html Thanks, Pino Toscano (2): src: start unifying version handling

This QEMU property is specific to x86/x86_64, so add it only on these architectures. --- lib/launch-direct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index bc43dcea2..3b848165c 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -519,8 +519,10 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) arg ("-rtc",

Hi, this adds an helper version struct, and uses it in the backends (for the libvirt and qemu versions) and inspection code. This also moves common code to that, so it is not repeated in many places. This should help with the small refactoring proposed with https://www.redhat.com/archives/libguestfs/2016-May/msg00070.html Thanks, Pino Toscano (2): src: start unifying version handling