> > > + if (kvm_cr0_mmu_role_changed(old_cr0, kvm_read_cr0(vcpu)) || > > > + kvm_cr4_mmu_role_changed(old_cr4, kvm_read_cr4(vcpu))) > > > + kvm_mmu_reset_context(vcpu); > > > } > > > > I'm wondering if kvm_vcpu_reset() should call kvm_mmu_reset_context() > > for a change in EFER.NX as well. > > Oooh. So there _should_ be no need. Paging has to be enabled for EFER.NX to > be relevant, and INIT toggles CR0.PG 1=>0 if paging was enabled and so is > guaranteed to trigger a context reset. And we do want to skip the context reset, > e.g. INIT-SIPI-SIPI when the vCPU has paging disabled should continue using the > same MMU. > > But, kvm_calc_mmu_role_common() neglects to ignore NX if CR0.PG=0, and so the > MMU role will be stale if INIT clears EFER.NX without forcing a context reset. > However, that's benign from a functionality perspective because the context > itself correctly incorporates CR0.PG, it's only the role that's borked. I.e. > KVM will fail to reuse a page/context due to the spurious role.nxe, but the > permission checks are always be correct. > > I'll add a comment here and send a patch to fix the role calculation. Thank you so much for the explanation ! I understand your intention and why it would be benign. Then, I'm wondering if kvm_cr4_mmu_role_changed() needs to be called here. Looking at the Intel SDM, in my understanding, all the bits kvm_cr4_mmu_role_changed() checks are relevant only if paging is enabled. (Or is my understanding incorrect ??) Thanks, Reiji
