Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Vitaly Kuznetsov <vkuznets@redhat.com>
To:     Tom Lendacky <thomas.lendacky@amd.com>
Cc:     Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Borislav Petkov <bp@suse.de>,
        Brijesh Singh <brijesh.singh@amd.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH 03/13] KVM: SVM: Move SEV module params/variables to sev.c
In-Reply-To: <672e86f7-86c7-0377-c544-fe52c8d7c1b9@amd.com>
References: <20210109004714.1341275-1-seanjc@google.com>
 <20210109004714.1341275-4-seanjc@google.com>
 <87sg7792l3.fsf@vitty.brq.redhat.com>
 <672e86f7-86c7-0377-c544-fe52c8d7c1b9@amd.com>
Date:   Mon, 11 Jan 2021 17:58:20 +0100
Message-ID: <87k0sj8l77.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Tom Lendacky <thomas.lendacky@amd.com> writes:

> On 1/11/21 4:42 AM, Vitaly Kuznetsov wrote:
>> Sean Christopherson <seanjc@google.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@google.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.

-- 
Vitaly