On 06/17/16 14:15, Eduardo Habkost wrote:
On Fri, Jun 17, 2016 at 09:11:16AM +0800, Haozhong Zhang wrote:
On 06/16/16 11:55, Eduardo Habkost wrote:
On Thu, Jun 16, 2016 at 12:04:50PM +0200, Paolo Bonzini wrote:
On 16/06/2016 08:05, Haozhong Zhang wrote:
From: Ashok Raj <ashok.raj@intel.com>
On Intel platforms, this patch adds LMCE to KVM MCE supported capabilities and handles guest access to LMCE related MSRs.
Signed-off-by: Ashok Raj <ashok.raj@intel.com> [Haozhong: macro KVM_MCE_CAP_SUPPORTED => variable kvm_mce_cap_supported Only enable LMCE on Intel platform Check MSR_IA32_FEATURE_CONTROL when handling guest access to MSR_IA32_MCG_EXT_CTL] Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> [...] @@ -6433,6 +6455,8 @@ static __init int hardware_setup(void)
kvm_set_posted_intr_wakeup_handler(wakeup_handler);
+ kvm_mce_cap_supported |= MCG_LMCE_P;
Ah, so virtual LMCE is available on all processors! This is interesting, but it also makes it more complicated to handle in QEMU; a new QEMU generally doesn't require a new kernel.
Eduardo, any ideas?
(CCing libvirt list)
As we shouldn't make machine-type changes introduce new host requirements, it looks like we need to either add a new set of CPU models (unreasonable), or expect management software to explicitly enable LMCE after ensuring the host supports it.
Or we could wait for a reasonable time after the feature is available in the kernel, and declare that QEMU as a whole requires a newer kernel. But how much time would be reasonable for that?
Long term, I believe we should think of a better solution. I don't think it is reasonable to require new libvirt code to be written for every single low-level feature that requires a newer kernel or newer host hardware. Maybe new introspection interfaces that would allow us to drop the "no new requirements on machine-type changes" rule?
Because new MSR (MSR_IA32_MCG_EXT_CTL) and new MSR bit (FEATURE_CONTROL_LMCE in MSR_IA32_FEATURE_CONTROL) are introduced by LMCE, QEMU requires new KVM which can handle those changes.
If I understood correctly, you are describing the second option above (declaring that QEMU as a whole requires a newer kernel).
I'm not familiar with libvirt. Does the requirement of new KVM capability bring any troubles to libvirt?
It does, assuming that we still support running QEMU under an older kernel where KVM doesn't LMCE. In this case, the pc-2.6 machine-type will run, but the pc-2.7 machine-type won't.
The requirement of new KVM capabilities based on the machine-type is a problem for livirt. libvirt have some host-capabilities APIs to allow software to check if the VM can be run on (or migrated to) a host, but none of them are based on machine-type.
This is not necessarily specific to libvirt: people may have their own configuration or scripts that use the default "pc" alias, and a QEMU upgrade shouldn't break their configuration.
Thanks for the explanation! If we disable LMCE in QEMU by default (even for -cpu host), will it still be a problem? That is, - pc-2.7 can continue to run on old kernels unless users explicitly require LMCE - existing libvirt VM configurations can continue to work on pc-2.7 because LMCE is not specified in those configurations and are disabled by default (i.e. no requirement for new kernels) - existing QEMU configurations/scripts using pc alias can continue to work on pc-27 for the same reason above. Thanks, Haozhong