On Tue, 5 Feb 2013 19:20:04 -0200 Eduardo Habkost <ehabk...@redhat.com> wrote:
> 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"). > > > [...] > Ok, lets drop this patch. I'll prepare another one that moves default setting to class_init().
