On Thu, May 25, 2023, Robert Hoo wrote: > On 5/23/2023 2:21 PM, Yan Zhao wrote: > IIUC, your saving comes from skips the intermediate state during boot, when > APs goes through setting MTRR, which would cause SPTE zap before your this > patch set. > > MHO was, now that your ignores other vCPU's MTRR settings (unless it is > different from BP's MTRR?), why not let each vCPU's MTRR set/update directly > set to the per-VM MTRR states (if differs from current value). It's guest > OS/BIOS's responsibility to keep the consistency anyway. And even if the > malfunction caused by the inconsistency might differ from that of native, > SDM doesn't clearly state how the malfunction should be, does it? > that's to say, anyone knows, when inconsistency happens, does it cause that > logical processor malfunction or in fact it impacts the global MTRR > settings? If the latter, I think leaving only the per-VM MTRR state aligns > with native. The MTRRs are not system wide or per-package though, they are per logical CPU. Yes, they "need" to be consistent with respect to one another, but only when the CPU is actually accessing memory. This is a big reason why trying to track MTRRs as a per-VM asset in KVM is so difficult/messy. Software doesn't rendezvous all CPUs and then do the write on just one CPU, each CPU does its own writes more or less independently. > BTW, with regard to KVM_X86_QUIRK_CD_NW_CLEARED, I see svm honors it while > vmx doesn't before it clear CR0.CD/NW. > > svm_set_cr0(): > > if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED)) > hcr0 &= ~(X86_CR0_CD | X86_CR0_NW); > > > vmx_set_cr0(): > > hw_cr0 = (cr0 & ~KVM_VM_CR0_ALWAYS_OFF); > > Perhaps vmx side can be fixed passingly? Sadly, no. SVM and VMX manage guest memtype completely differently. VMX doesn't allow CR0.CD=1 when VMX is enabled, and so KVM needs to emulate CR0.CD via the EPT memtype.
