X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=src%2Flaunch.c;h=a2a9beaa53f5913e0e6bd51dcd73a8fd34536818;hp=ecc0464a88edfa09d20a3b6cc964d6c727d9bdd4;hb=70daccfe4e9939078436c2830928d8e53432dd84;hpb=607aa95de927b5b8e4b212655c71bf21acbba372;ds=sidebyside diff --git a/src/launch.c b/src/launch.c index ecc0464..a2a9bea 100644 --- a/src/launch.c +++ b/src/launch.c @@ -487,21 +487,30 @@ launch_appliance (guestfs_h *g) if (qemu_supports (g, "-nodefconfig")) add_cmdline (g, "-nodefconfig"); - /* qemu sometimes needs this option to enable hardware - * virtualization, but some versions of 'qemu-kvm' will use KVM - * regardless (even where this option appears in the help text). - * It is rumoured that there are versions of qemu where supplying - * this option when hardware virtualization is not available will - * cause qemu to fail, so we we have to check at least that - * /dev/kvm is openable. That's not reliable, since /dev/kvm - * might be openable by qemu but not by us (think: SELinux) in - * which case the user would not get hardware virtualization, - * although at least shouldn't fail. A giant clusterfuck with the - * qemu command line, again. + /* The qemu -machine option (added 2010-12) is a bit more sane + * since it falls back through various different acceleration + * modes, so try that first (thanks Markus Armbruster). */ - if (qemu_supports (g, "-enable-kvm") && - is_openable (g, "/dev/kvm", O_RDWR)) - add_cmdline (g, "-enable-kvm"); + if (qemu_supports (g, "-machine")) { + add_cmdline (g, "-machine"); + add_cmdline (g, "accel=kvm:tcg"); + } else { + /* qemu sometimes needs this option to enable hardware + * virtualization, but some versions of 'qemu-kvm' will use KVM + * regardless (even where this option appears in the help text). + * It is rumoured that there are versions of qemu where supplying + * this option when hardware virtualization is not available will + * cause qemu to fail, so we we have to check at least that + * /dev/kvm is openable. That's not reliable, since /dev/kvm + * might be openable by qemu but not by us (think: SELinux) in + * which case the user would not get hardware virtualization, + * although at least shouldn't fail. A giant clusterfuck with the + * qemu command line, again. + */ + if (qemu_supports (g, "-enable-kvm") && + is_openable (g, "/dev/kvm", O_RDWR)) + add_cmdline (g, "-enable-kvm"); + } /* Newer versions of qemu (from around 2009/12) changed the * behaviour of monitors so that an implicit '-monitor stdio' is @@ -622,11 +631,13 @@ launch_appliance (guestfs_h *g) close (wfd[1]); close (rfd[0]); + /* Stdin. */ if (dup (wfd[0]) == -1) { dup_failed: perror ("dup failed"); _exit (EXIT_FAILURE); } + /* Stdout. */ if (dup (rfd[1]) == -1) goto dup_failed; @@ -634,12 +645,9 @@ launch_appliance (guestfs_h *g) close (rfd[1]); } -#if 0 - /* Set up a new process group, so we can signal this process - * and all subprocesses (eg. if qemu is really a shell script). - */ - setpgid (0, 0); -#endif + /* Put qemu in a new process group. */ + if (g->pgroup) + setpgid (0, 0); setenv ("LC_ALL", "C", 1); @@ -668,6 +676,14 @@ launch_appliance (guestfs_h *g) pid_t qemu_pid = g->pid; pid_t parent_pid = getppid (); + /* It would be nice to be able to put this in the same process + * group as qemu (ie. setpgid (0, qemu_pid)). However this is + * not possible because we don't have any guarantee here that + * the qemu process has started yet. + */ + if (g->pgroup) + setpgid (0, 0); + /* Writing to argv is hideously complicated and error prone. See: * http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/ps_status.c?rev=1.33.2.1;content-type=text%2Fplain */