From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAC06ECAAA1 for ; Thu, 27 Oct 2022 18:01:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236371AbiJ0SBQ (ORCPT ); Thu, 27 Oct 2022 14:01:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236191AbiJ0SBA (ORCPT ); Thu, 27 Oct 2022 14:01:00 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 528F41EAC8 for ; Thu, 27 Oct 2022 10:59:46 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id g24so2343803plq.3 for ; Thu, 27 Oct 2022 10:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=k9IjDL5JWPlrnxsJJxEdunDpxxIPr2PnubjnaqSEwb4=; b=fAXRGsXO9T0rVErFQRaqRc9PON2BHW/sPR0NJalJ9Jad8TFOi63lfrXx+Qr4g1y/rt 8Um/s2hFWMnq0ZYlnODum3Ka6hps+k8EUMiUNDK8VeFZO5W1onzj6pn7P1r6f4KkvvyR JKfdeir7oAydSoXS4iEfaZRC4CqREkrS8n1lTV5J9r3z/QG228gGvrc2BfpSvqCrF4tN fwS5PoHK6fUA96ivKQVZgK5MLvEIAXEQTFhn0HN+iYL18SI0aX3N7j4YS4mtBuC3fp3R iElh2Fo36Oj0islcASQPO2huArN8fvJJH4gkYDnV+GSF+D0gP+D4WRWkyxfWUnqfgQFL 6LyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k9IjDL5JWPlrnxsJJxEdunDpxxIPr2PnubjnaqSEwb4=; b=Ru3r3q1z25XhyOLN+UcFU6Kjy9dDWGQVYjTQLMqIz65FAEc0P++P/CwG2tZhCl2Rfu SL1kl2euj5Tn1uGsf2d8Ogt9lKNz2HCWw2OE0uJiKeYDjPiWkhYovIVC15mFmgLZEEFU lxcPoTIBZRE3z3J9J8A9dP8AIhHMZCjCQPKHaLPbelXf/+tHkH0tf+BsBemjslzwbrQc EuiOhODLKp7JrU+yrHL15Wulne3AIh2hdbsXpWxU6WrbhGXpi1OQPIQPZk657BzW9pEW dCmWdoCjwIng4GbHDhbBHl0XFhCU6ZIHuOm6oivGkPbAmyaYFwqFjmmABhYThRuF6mLO ZOnw== X-Gm-Message-State: ACrzQf1QZpepwIKRHcsFE6CzJ19AmjMHm0N7OIhHuxmtmobq1gGJUCQI uvoLQLUTZbSKsp8WA1A0QVwzlw== X-Google-Smtp-Source: AMsMyM51ndGRH8GQDhjsXKGE6fXDuBR48obKHClQus7mENGt9nZN2K6NGCLN9rN699E6OeBjC+xpQg== X-Received: by 2002:a17:90b:384a:b0:213:2907:a528 with SMTP id nl10-20020a17090b384a00b002132907a528mr11393920pjb.183.1666893586206; Thu, 27 Oct 2022 10:59:46 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id n5-20020a170902e54500b00186f0f59c85sm1116689plf.235.2022.10.27.10.59.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Oct 2022 10:59:45 -0700 (PDT) Date: Thu, 27 Oct 2022 17:59:42 +0000 From: Sean Christopherson To: Peter Gonda Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, marcorr@google.com, michael.roth@amd.com, thomas.lendacky@amd.com, joro@8bytes.org, mizhang@google.com, pbonzini@redhat.com, andrew.jones@linux.dev Subject: Re: [V4 6/8] KVM: selftests: add library for creating/interacting with SEV guests Message-ID: References: <20220829171021.701198-1-pgonda@google.com> <20220829171021.701198-7-pgonda@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 27, 2022, Peter Gonda wrote: > On Wed, Oct 19, 2022 at 10:34 AM Sean Christopherson wrote: > > > > On Tue, Oct 18, 2022, Peter Gonda wrote: > > > On Mon, Oct 17, 2022 at 2:34 PM Sean Christopherson wrote: > > > > > > > > On Mon, Oct 17, 2022, Peter Gonda wrote: > > > > > I think this means we don't need to add VM_MODE_PXXV48_4K_SEV since we > > > > > can set up the c-bit from inside of vm_sev_create_*(), thoughts? > > > > > > > > Configuring the C-bit inside vm_sev_create_*() won't work (at least not well). > > > > The C-bit needs to be known before kvm_vm_elf_load(), i.e. can't be handled after > > > > __vm_create(), and needs to be tracked inside the VM, i.e. can't be handled before > > > > __vm_create(). > > > > > > > > The proposed kvm_init_vm_address_properties() seems like the best fit since the > > > > C-bit (and TDX's S-bit) is stolen from GPA space, i.e. directly affects the other > > > > values computed in that path. > > > > > > > > As for the kvm_vm_arch allocation ugliness, when we talked off-list I didn't > > > > consider the need to allocate in kvm_init_vm_address_properties(). That's quite > > > > gross, especially since the pointer will be larger than the thing being allocated. > > > > > > > > With that in mind, adding .../include//kvm_util.h so that "struct kvm_vm_arch" > > > > can be defined and referenced directly doesn't seem so bad. Having to stub in the > > > > struct for the other architectures is annoying, but not the end of the world. > > > > > > I'll make "struct kvm_vm_arch" a non pointer member, so adding > > > /include//kvm_util.h files. > > > > > > But I think we do not need VM_MODE_PXXV48_4K_SEV, see: > > > > I really don't want to open code __vm_create() with a slight tweak. E.g. the > > below code will be broken by Ricardo's series to add memslot0 is moved out of > > ____vm_create()[1], and kinda sorta be broken again by Vishal's series to add an > > arch hook to __vm_create()[2]. > > > > AFAICT, there is no requirement that KVM_SEV_INIT be called before computing the > > C-Bit, the only requirement is that KVM_SEV_INIT is called before adding vCPUs. > > > > [1] https://lore.kernel.org/all/20221017195834.2295901-8-ricarkol@google.com > > [2] https://lore.kernel.org/all/YzsC4ibDqGh5qaP9@google.com > > Oh I misunderstood your suggestion above. > > I should make KVM_SEV_INIT happen from kvm_arch_vm_post_create(). Add > VM_MODE_PXXV48_4K_SEV for c-bit setting inside of > kvm_init_vm_address_properties(). > > Inside of vm_sev_create_with_one_vcpu() I use > __vm_create_with_vcpus(), then call KVM_SEV_LAUNCH_FINISH. > > Is that correct? Yep, I'm pretty sure that was what I was thinking.