[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <927cbe06-7183-1153-95ea-f97eb4ff12f6@redhat.com>
Date: Wed, 26 May 2021 18:30:02 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>,
Maxim Levitsky <mlevitsk@...hat.com>
Cc: Ben Gardon <bgardon@...gle.com>, Jim Mattson <jmattson@...gle.com>,
Junaid Shahid <junaids@...gle.com>,
Peter Xu <peterx@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, kvm <kvm@...r.kernel.org>
Subject: Re: Writable module parameters in KVM
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.
Paolo
Powered by blists - more mailing lists