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.
