Re: [Qemu-devel] Not introducing new host-side requirements on new machine-type versions (was Re: [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models)

[Paolo Bonzini <pbonzini@redhat.com>]

On 24/06/2015 17:44, Eduardo Habkost wrote:
> As long as QEMU guarantees that, so we don't change existing CPU models
> (in new machines) in a way that introduces new host-side dependencies,
> we will be OK.
> 
> We may need something new to implement this guarantee for KVM features,
> though. libvirt will need something that says "please don't enable any
> KVM CPUID bits silently for me, let me ask for them explicitly". But
> that won't be as drastic as requiring "-cpu custom".
> 
> That have some consequences in the way we add new CPU models and
> implement CPU model changes. For example: until we know all the features
> we want in a CPU model are already available and supported in the latest
> kernel, we won't add a new CPU model. The choice of features in CPU
> models

... that require host-side support.

> should be "final" as soon as we add the CPU model, so CPU model
> changes should never introduce new host-side requirements.

Just like we are doing for ARAT, we can always hack around the
limitation in kvm_arch_get_supported_cpuid, because new features that
require kernel support are overall rare.

It happened for TSC_DEADLINE/RDTSCP/XSAVE (Sandy Bridge), and it will
happen for MPX/XSAVES (Skylake), but that was pretty much it in the last
few years.

Paolo

> If a CPU
> model change requires some additional KVM code or newer host CPU, we
> need to add a new CPU model name. We must agree on that and document it,
> because I expect to see some complaints in the future when enforcing
> this rule.