On 05/10/2018 16:22, Peter Maydell wrote: > On 5 October 2018 at 15:13, Thomas Huth <th...@redhat.com> wrote: >> When compiling with "--disable-tcg", we currently still use "tcg" >> as default accelerator. "kvm" should be used in this case instead. > > This part is non-controversial and makes good sense.
Though it probably should be extended to "whpx" and "hvf" (probably "xen" too if !CONFIG_KVM). >> Also, some downstream distros provide QEMU binaries which have "kvm" >> in their names (e.g. "qemu-kvm" on RHEL or "kvm" on Ubuntu) that use >> KVM by default - and some users might want to do something similar >> with upstream binaries, too. Accomodate them by using "kvm:tcg" as >> default when we detect such a binary name. > > This part is much riskier and less clearly a good plan -- > do we really want our behaviour to vary based on the name > of the executable? Distros who want that sort of qemu-kvm > wrapper generally are providing it already (the Ubuntu one > is a 2-line shell script). I think it makes sense. At least RHEL has qemu-kvm but no qemu-system-x86_64, so it has a non-upstream patch to change the accelerator; for other distros there are two benefits: 1) now: they could switch to a symlink 2) later: right now, "-accel kvm:tcg" works but we should instead switch that to "-accel kvm -accel tcg", and deprecate "-M accel=kvm:tcg" (which doesn't let you specify accelerator options). I don't really like second guessing based on argv[0], because argv[0] can actually be spoofed by the exec-ing program. One idea could be to pick the "best" KVM-enabled emulator that we can build, and also install it as qemu-kvm with some magic to flip the default to kvm:tcg. But that can be done later; something like Thomas's patch is nice to have, and good enough. Paolo
