similar to: [PATCH 1/2] launch: direct: Use a single -machine [type, ]accel=... option.

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

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

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

See: https://bugzilla.redhat.com/show_bug.cgi?id=1339977 --- src/launch-direct.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index 20f6471..6450d7e 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -382,9 +382,12 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) MACHINE_TYPE

Hi, things are progressing slowly, but I feel that eventually I'll be getting there: supermin can be built on all Linux-based architectures that are part of Debian/unstable[1] -- (except for sparc, but I'll ignore that for now.) libguestfs on the other hand currently fails launching the appliance (necessary for running tests) on everything but x86 and mips. Apparently, qemu-system-arm

NOTE: Not for upstream, yet. This depends on 3 non-upstream patches. - The qemu rework in libguestfs, which in turn depends on what Pino is up to. - Support for '-L ?' in qemu: https://lists.gnu.org/archive/html/qemu-devel/2016-05/threads.html#02596 - Support for bios-fast.bin in qemu: https://lists.gnu.org/archive/html/qemu-devel/2016-05/threads.html#02408 This commit

This commit uses -bios bios-fast.bin if available, which basically stops SeaBIOS from trying to do PCI probing during boot, which is a waste of time when using the -kernel option. v1 -> v2: - Rebase on top of Pino's work. This still has 3 dependencies: - The qemu memoization work (v2). - Support for '-L ?' in qemu:

The previous code duplicated a lot of common code for reading and writing the cache file per data field. This change simply factors out that common code. This makes it simpler to add new tests in future. This is just refactoring, it should have no effect. --- lib/qemu.c | 375 +++++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 238 insertions(+), 137 deletions(-)

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 -

Patches 1 & 2 were posted previously here: https://www.redhat.com/archives/libguestfs/2016-May/msg00134.html Patch 3 is a hack so I can test this using my own version of qemu (the `-L ?' stuff is not upstream). Patch 4 is where the real action takes place: Replace the caching of qemu features in blob-like files with a sqlite database. Probably the best way to approach this patch is to

Because of previous automated commits, such as changing 'guestfs___' -> 'guestfs_int_', several function calls no longer lined up with their parameters, and some lines were too long. The bulk of this commit was done using emacs batch mode and the technique described here: http://www.cslab.pepperdine.edu/warford/BatchIndentationEmacs.html The changes suggested by emacs were

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),

In some places when generating XML output in C code we use some clever macros: start_element ("memory") { attribute ("unit", "MiB"); string ("%d", g->memsize); } end_element (); This commit which is mostly refactoring moves the repeated definitions of these macros into a common header file. I also took this opportunity to change / clean up

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

v2 -> v3: - Rebase on top of the other patches. Rich.

NOTE: not for upstream, yet. v1 -> v2: - Remove the dependency on enabling ACPI, since ACPI is now enabled all the time. Rich.

On Monday 02 December 2013 09:09:44 Richard W.M. Jones wrote: > On Mon, Dec 02, 2013 at 01:17:09AM +0100, Pino Toscano wrote: > > On Friday 29 November 2013 18:53:38 you wrote: > > > > > I'm marking options with NONE (not used at all), or M (used in > > > > > master) and/or RH7 (used in rhel-7.0). > > > > > > > > > > > *

From: "Richard W.M. Jones" <rjones at redhat.com> CVE-2011-4127 is a serious qemu & kernel privilege escalation bug found by Paolo Bonzini. http://seclists.org/oss-sec/2011/q4/536 An untrusted guest kernel is able to issue special SG_IO ioctls on virtio devices which qemu passes through to the host kernel without filtering or sanitizing. These ioctls allow raw sectors from

This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.