On Tue, 2018-04-10 at 09:52 +0100, Daniel P. Berrangé wrote: > On Tue, Apr 10, 2018 at 09:41:33AM +0200, Andrea Bolognani wrote: > > I figure the people not explicitly specifying a CPU model on the > > command line will probably also use '-M virt' instead of versioned > > machine types, which means they will get a different guest behavior > > after upgrading QEMU regardless. > > Libvirt uses versioned machine types and does not specify -cpu unless the > user has added <cpu> to their XML. IOW libvirt assumes the default CPU > model is stable because that's what QEMU has promised in the past.
Hm, you have a point. I wonder how well that works in practice, though. I started a guest with no <cpu> element on my laptop and it ended up having vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 2.5+ stepping : 3 which I guess translates to the qemu64 CPU model, based on the description. I have verified the -cpu option is not present on the command line. The name seems to imply that if I were using a QEMU release older than 2.5 I would get a different CPU model, but maybe the stable CPU guarantee you mention is just a fairly recent development. I also know that ppc64 performs some trickery if you don't specify a CPU model, so by default you get a behavior which is pretty close to using -cpu host. Basically I'm wondering how reasonable it is to expect a migratable machine and a stable guest ABI when relying on QEMU defaults instead of explicitly picking a CPU model. -- Andrea Bolognani / Red Hat / Virtualization
