On 1/8/2018 11:01 AM, Paolo Bonzini wrote: > On 08/01/2018 17:48, Dr. David Alan Gilbert wrote: >>> If your hypervisor is lying to you about the primary family, then all >>> bets are off. I don't expect there will be any production systems doing >>> this. >> It's not that an unusual thing to do on qemu/kvm - to specify the lowest >> common denominator of the set of CPUs in your data centre (for any one >> vendor); it does tend to get some weird combinations. > > Agreed. But on a hypervisor we pretty much know that: > > - the MSR_AMD64_DE_CFG doesn't exist unless you have a fix > > - setting the MSR_AMD64_DE_CFG bit to 1 if you have a fix can be done > independent of the family > > So all KVM needs is a X86_FEATURE_LFENCE_SERIALIZE, it doesn't matter if > it's because of the family or because Linux has set MSR_F10H_DE_CFG. > The guest will either try setting the MSR bit and #GP, or it will find > it already set and do nothing. > > Of course no code for this has been written yet. >
Hi Paolo, What would be the best way to approach the MSR support? I was thinking of just recognizing a write to that MSR but not actually doing anything and, on read, just returning a value with the single bit set if LFENCE is serializing and not worrying about the full contents of the MSR. Or I could save the value so that it could also be host initiated and only allow the LFENCE serialization bit to be set if the LFENCE_RDTSC feature is enabled. Thanks, Tom > Paolo >
