[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <X/4gHlZJvpem8SLd@google.com>
Date: Tue, 12 Jan 2021 14:18:06 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: Tom Lendacky <thomas.lendacky@....com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Borislav Petkov <bp@...e.de>,
Brijesh Singh <brijesh.singh@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 03/13] KVM: SVM: Move SEV module params/variables to sev.c
On Mon, Jan 11, 2021, Vitaly Kuznetsov wrote:
> Tom Lendacky <thomas.lendacky@....com> writes:
>
> > On 1/11/21 4:42 AM, Vitaly Kuznetsov wrote:
> >> Sean Christopherson <seanjc@...gle.com> writes:
> >>
> >>> Unconditionally invoke sev_hardware_setup() when configuring SVM and
> >>> handle clearing the module params/variable 'sev' and 'sev_es' in
> >>> sev_hardware_setup(). This allows making said variables static within
> >>> sev.c and reduces the odds of a collision with guest code, e.g. the guest
> >>> side of things has already laid claim to 'sev_enabled'.
> >>>
> >>> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> >>> ---
> >>> arch/x86/kvm/svm/sev.c | 11 +++++++++++
> >>> arch/x86/kvm/svm/svm.c | 15 +--------------
> >>> arch/x86/kvm/svm/svm.h | 2 --
> >>> 3 files changed, 12 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> >>> index 0eeb6e1b803d..8ba93b8fa435 100644
> >>> --- a/arch/x86/kvm/svm/sev.c
> >>> +++ b/arch/x86/kvm/svm/sev.c
> >>> @@ -27,6 +27,14 @@
> >>>
> >>> #define __ex(x) __kvm_handle_fault_on_reboot(x)
> >>>
> >>> +/* enable/disable SEV support */
> >>> +static int sev = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
> >>> +module_param(sev, int, 0444);
> >>> +
> >>> +/* enable/disable SEV-ES support */
> >>> +static int sev_es = IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT);
> >>> +module_param(sev_es, int, 0444);
> >>
> >> Two stupid questions (and not really related to your patch) for
> >> self-eduacation if I may:
> >>
> >> 1) Why do we rely on CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT (which
> >> sound like it control the guest side of things) to set defaults here?
> >
> > I thought it was a review comment, but I'm not able to find it now.
> >
> > Brijesh probably remembers better than me.
> >
> >>
> >> 2) It appears to be possible to do 'modprobe kvm_amd sev=0 sev_es=1' and
> >> this looks like a bogus configuration, should we make an effort to
> >> validate the correctness upon module load?
> >
> > This will still result in an overall sev=0 sev_es=0. Is the question just
> > about issuing a message based on the initial values specified?
> >
>
> Yes, as one may expect the result will be that SEV-ES guests work and
> plain SEV don't.
KVM doesn't issue messages when it overrides other module params due to
disable requirements, e.g. ept=0 unrestricted_guest=1 is roughly equivalent.
Not that what KVM currently does is right, but at least it's consistent. :-)
And on the other hand, I think it's reasonable to expect that specifying only
sev=0 is sufficient to disable both SEV and SEV-ES, e.g. to turn them off when
they're enabled by default.
Powered by blists - more mailing lists