On Tue, Feb 05, 2013 at 08:47:29PM +0100, Igor Mammedov wrote: > On Tue, 5 Feb 2013 17:04:26 -0200 > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > On Tue, Feb 05, 2013 at 07:46:09PM +0100, Igor Mammedov wrote: > > > On Tue, 5 Feb 2013 15:53:04 -0200 > > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > > > On Tue, Feb 05, 2013 at 05:39:24PM +0100, Igor Mammedov wrote: > > > > > ORing kvm_default_features to def->kvm_features might set unsupported > > > > > bits if kvm_arch_get_supported_cpuid() returns less bits set than in > > > > > kvm_default_features. Fix it by removing kvm_default_features and > > > > > using > > > > > only what kvm_arch_get_supported_cpuid() returns. > > > > > > > > This is exactly what we _must not_ do! We can't change CPUID bits in a > > > > machine-type or we will change the guest ABI. We must keep them stable > > > > for a machine-type and: > > > > > > > > * Not change if QEMU is upgraded; > > > > * Not change if the host kernel is upgraded; > > > > * Not change if running on different host hardware. > > > Is all of this applicable to CPU 'host' or only to built-in cpu_models? > > > > This applies only to the built-in CPU models and the stable (versioned) > > machine-types. > > > > -cpu host is special and is expected to break the rules above. We could > > also create a "pc-next" machine-type where those rules could be broken. > Isn't default machine like pc-next?
No, the default machine is versioned (today it is "pc-i440fx-1.4"). > [...] -- Eduardo