Re: Writable module parameters in KVM

[Sean Christopherson <seanjc@google.com>]

On Wed, May 26, 2021, Ben Gardon wrote:
> I don't know if there's a great way to formally encode this distinction, but
> I see two major classes of writable params in terms of complexity:
>
> 1. parameters that are captured on VM creation and follow the life of
> the VM e.g. the TDP MMU
>
> 2. parameters which have an effect on all VMs on the system when
> changed e.g. internally we have sysctls to change NX reclaim
> parameters
> 
> I think class 1 is substantially easier to reason about from a code
> perspective, but might be more confusing to userspace, as the current
> value of the parameter has no bearing on the value captured by the VM.
> Class 2 will probably be more complex to implement, require
> synchronization, and need a better justification.

That assessement isn't universally true, e.g. 'npt' and 'ept' could be snapshotted
and put into (1), but as discussed, the fallout would be spectactular.  And on
the other side, the flush/sync on reuse flag is fully dynamic and falls into (2),
yet is trivial to implement.

That said, I don't think it matters because I don't think classifying params
will change anyone's behavior.  Each param would still need to be justified and
reviewed on a case-by-case basis.