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

Reply via email to