> > 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. > > Does this mean QEMU can't set CPUID values that won't match the host with the existing implementation, or this won't matter for > well-behaved guests that don't try to set reserved bits on the MSRs? > > > > 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) > > What do you mean by whitelist? > > > > > > Others, currently only CPUID[EAX=14h,ECX=0].ECX[31] must match, there > > is no way to emulate the "wrong" value. > > In this case we could make it configurable but require the host and guest value to always match. > > This might be an obstacle to enabling intel-pt by default (because it could make VMs not migratable to newer hosts), but may allow > the feature to be configured in a predictable way. > > > > > > 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. > > This could be handled by QEMU. There's no requirement that all GET_SUPPORTED_CPUID values should be validated by simple bit > masking. So, we can get a lower value on the numeric of CPUID[EAX=14h,ECX=1].EAX[2:0] between different host. How about other bits of CPUID[14] ? Can we do like this as well? Thanks, Luwei Kang > > > > > > CPUID[EAX=14h,ECX=0].EAX is the maximum subleaf. It should be > > (barring guest bugs) okay to always present leaf 1. > > > > Paolo > > -- > Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list