On Wed, Oct 11, 2023, David Woodhouse wrote: > On Tue, 2023-10-10 at 16:25 -0700, Sean Christopherson wrote: > > On Tue, Oct 10, 2023, David Woodhouse wrote: > But I'm confused here. Even if I don't go as far as actually making > CR4.SMEP a guest-owned bit, and KVM still ends up handling it in > kvm_post_load_cr4()... why does KVM need to completely unload and > reinit the MMU? Would it not be sufficient just to refresh the role > bits, much like __kvm_mmu_refresh_passthrough_bits() does for CR0.WP? Maybe? It largely hasn't happened simply because no one (yet) cares enough about the performance of other bits to force the issue. > (And what about flushing the hardware TLB, as Jim mentioned. I guess if > it's guest-owned we trust the CPU to do that, and if it's trapped then > KVM is required to do so)? TBH, I forgot that clearing SMEP architecturally requires a TLB flush for the current PCID on Intel. I *think* it's actually fine so long as TDP is enabled. Ah, yes, it's fine. Well, either that or kvm_invalidate_pcid() is buggy :-) Relying on the CPU to flush the hardware TLBs is definitely ok, I was just trying to think if there were any KVM artifacts that would need to be flushed/invalidated. I can't think of any, e.g. KVM already disable GVA-based MMIO caching when TDP is enabled, L1 is responsible for its virtual TLB if L1 is shadowing legacy paging for L2, and if L1 is using EPT, i.e. KVM is shadowing L1 EPT and thus has a virtual TLB for L2, then the PCID is irrelevant (doesn't affect EPT translations).
