On Fri, Aug 19, 2022, Paolo Bonzini wrote: > On 8/19/22 18:21, David Matlack wrote: > > On Wed, Aug 3, 2022 at 3:50 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > > Fully re-evaluate whether or not MMIO caching can be enabled when SPTE > > > masks change; simply clearing enable_mmio_caching when a configuration > > > isn't compatible with caching fails to handle the scenario where the > > > masks are updated, e.g. by VMX for EPT or by SVM to account for the C-bit > > > location, and toggle compatibility from false=>true. > > > > > > Snapshot the original module param so that re-evaluating MMIO caching > > > preserves userspace's desire to allow caching. Use a snapshot approach > > > so that enable_mmio_caching still reflects KVM's actual behavior. > > > > Is updating module parameters to reflect the actual behavior (vs. > > userspace desire) something we should do for all module parameters? > > > > I am doing an unrelated refactor to the tdp_mmu module parameter and > > noticed it is not updated e.g. if userspace loads kvm_intel with > > ept=N. > > If it is cheap/easy then yeah, updating the parameters is the right thing to > do. Generally, however, this is only done for kvm_intel/kvm_amd modules > that depend on hardware features, because they are more important for > debugging user issues. (Or at least they were until vmx features were added > to /proc/cpuinfo). IMO, unless it's _really_ hard, KVM should keep the parameters up-to-date with reality, e.g. so that userspace can assert that a feature is fully enabled, either for testing purposes (unrestricted guest?) or to prevent running with a "bad" config. We've had at least one internal OMG-level bug where KVM effectively ran with the wrong MMU configuration, and IIRC one of the actions taken in response to that was to assert on KVM's parameters post-load.
