On Wed, Oct 11, 2023 at 1:21 AM David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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? > > (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)? Yes, guest-owned bits become the responsibility of the CPU. With the TDP MMU, KVM probably should not intercept writes to %cr4 at all. I'd argue that it's better to construct guest paging attributes from first principles every time KVM needs to know, rather than intercepting any operation that may change guest paging attributes. If that's too expensive, perhaps KVM is emulating too many instructions. :) Particularly aggravating to me is that too many of these cost/benefit decisions were made without consideration of nested virtualization. At one time, someone observed that Linux hardly ever writes %cr4, so it must be cheap to intercept. How ironic that they didn't consider the fact that KVM is part of Linux, and KVM writes %cr4 all the time! If the cost of determining paging attributes from first principles is really prohibitive, maybe the solution is more flexibility. KVM can start by intercepting writes to %cr4, but if the rate of intercepts is egregious, it should do something else.
