On 18/01/2018 14:24, Eduardo Habkost wrote: > However, if there's a simple way to make it possible to migrate > between hosts with different CPUID[14h] data, it would be even > better. With the current KVM intel-pt implementation, what > happens if the CPUID[14h] data seen by the guest doesn't match > exactly the CPUID[14h] leaves from the host? Some bits in there can be treated as CPU features (e.g. EBX bit 0 "CR3 filtering support"). Probably we should handle these in KVM right now. KVM needs to compute a mask of valid 1 bits for IA32_RTIT_CTL based on CPUID, and apply it when the MSR is written. It also needs to whitelist bits like we do for other feature words. These include: - CPUID[EAX=14h,ECX=0].EBX - CPUID[EAX=14h,ECX=0].ECX except bit 31 - CPUID[EAX=14h,ECX=1].EAX bits 16:31 (if CPUID[EAX=14h,ECX=0].EBX[3]=1) - CPUID[EAX=14h,ECX=1].EBX (if CPUID[EAX=14h,ECX=0].EBX[1]=1) Others, currently only CPUID[EAX=14h,ECX=0].ECX[31] must match, there is no way to emulate the "wrong" value. Others, currently only CPUID[EAX=14h,ECX=1].EAX[2:0] are numeric values, and it's possible to emulate a lower value than the one in the processor. CPUID[EAX=14h,ECX=0].EAX is the maximum subleaf. It should be (barring guest bugs) okay to always present leaf 1. Paolo
