On Tue, Apr 24, 2018 at 10:59:04AM +0800, Wanpeng Li wrote: > 2018-04-18 18:36 GMT+08:00 Paolo Bonzini <pbonzini@xxxxxxxxxx>: > > On 18/04/2018 11:03, Eduardo Habkost wrote: > >>>> QEMU setting ucode_rev automatically using the host value when > >>>> using "-cpu host" (with no need for explicit ucode_rev option) > >>>> makes sense to me. > >>> QEMU can't get the host value by rdmsr MSR_IA32_UCODE_REV directly > >>> since rdmsr will #GP when ring !=0, any idea? > >> By looking at kvm_get_msr_feature(), it looks like > >> ioctl(system_fd, KVM_GET_MSRS) would return the host MSR value > >> for us. > > > > Yes, that's exactly what it was introduced for (together with other MSRs > > including VMX capabilities). > > How about the live migration? What will happen if the source and > destination machines have different microcode version? You would need to include the microcode version in the migration stream. But this brings another point - what if we want to manifest certain new CPUID bits? For example, see: https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf 5.3: "To remedy this situation, an operating system running as a VM can query bit 2 of the IA32_ARCH_CAPABILITIES MSR, known as “RSB Alternate” (RSBA). When RSBA is set, it indicates that the VM may run on a processor vulnerable to exploits of Empty RSB conditions regardless of the processor’s DisplayFamily/DisplayModel signature, and that the operating system should deploy appropriate mitigations. Virtual machine managers (VMM) may set RSBA via MSR interception to indicate that a virtual machine might run at some time in the future on a vulnerable processor." Perhaps the guest should do a bit of sampling of various CPUIDs as the migration has been done? Is there a nice KVM hook inside of the guest to do this? > > Regards, > Wanpeng Li
