On Wed, May 26, 2021 at 9:30 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On 26/05/21 17:44, Sean Christopherson wrote:
> >> Sure, making them writable is okay.
> >
> > making a param writable (new or existing) must come with strong
> > justification for taking on the extra complexity.
>
> I agree. It's the same for every change, and it's the reason why most
> parameters are read-only: no justification for the extra complexity.
> But if somebody has a usecase, it can be considered.
>
> > Making 'npt' writable is probably feasible ('ept' would be beyond messy), but I
> > strongly prefer to keep it read-only. The direct impacts on the MMU and SVM
> > aren't too bad, but NPT is required for SEV and VLS, affects kvm_cpu_caps, etc...
> > And, no offense to win98, there's isn't a strong use case because outside of
> > personal usage, the host admin/VMM doesn't know that the guest will be running a
> > broken kernel.
>
> Making 'npt' writable would be beyond messy too; allowing select VMs to
> disable EPT/NPT might be simpler, but not that much. I can't say
> offhand if the code would be ugly or not.
Thanks for the guidance all. We'll probably send out more writable
module params in the future in that case, and will add a Documentation
file whenever we send out the first one.
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.
>
> Paolo
>
