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 0353DC433FE for ; Mon, 17 Oct 2022 18:04:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230494AbiJQSEk (ORCPT ); Mon, 17 Oct 2022 14:04:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230486AbiJQSEf (ORCPT ); Mon, 17 Oct 2022 14:04:35 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68E6613F67 for ; Mon, 17 Oct 2022 11:04:33 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id l6so11133639pgu.7 for ; Mon, 17 Oct 2022 11:04:33 -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=drU3O/+nGrdgy6WMvD6hVrTFvRlUohf8Zzl84rmZ2yQ=; b=HXDzvzxUEPXF8gRIh1ZWqTSePTIzEruLotn0oKCLBkUbTNT01bZzUDXGcPHZ7smqbA JzbhVdVMZdS4ku0TM9KOqVdl5fBf2nU3XvGlf2GPjGSa1iVeXa4qcnCg7FQmArF2F1jY M0AiKOMuBlrmxZWgeB93M2gJn3itRtzlzZPhegmxIsgafHged2ZW33vomJf+hhB7/JUr UCIiBHNKc/cOWuj4BksIRLREcwpmLYEbP9OxuslD09Z+3UZOh7CdwOn3htaTg08N2AbY 8Hr8VtX/K0Jb2b9ohvHEvN4b82ZOiV7LFN7k/Tj7IC7i7OYCi1VmpIlUQ9l7AgCLfw7L Uq4Q== 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=drU3O/+nGrdgy6WMvD6hVrTFvRlUohf8Zzl84rmZ2yQ=; b=ZvH1OGnklh+m+D4yyToYiHhbWwtUQqya2g9DY3/F+LxZ9e6Cu0Tii8U2WvO3aP+cMc 8e7iZlKvty3q7UKarQ4GY1vHbXreNWUvv9kM5hfUL5btgT1/78zcUG8bnpwM8W10majL dJS4hoaewFt52XaO723Cr78PWMUTj+1s5MLusQqFfGDjNnBhwqEFo+poVME+1xJqTGiu 2Q8Sa92bc4y8usmfSOGuneAopxZwwk6I2IQYS/0Sp681IGaPG6cvE9vvIV32l1ATHbPM ytrkW37gus4M81gcwXu3FDhp/2hjJDmn1BfMwI++pKmF4ae6dCXK0zJJiyBevx0HWX2Z avow== X-Gm-Message-State: ACrzQf3S98ddfIQ3WFCWbQxabBswIFi/o9RUbk2Sl68TUgGJxbHsrAZ2 kM4U67DfL1Kpo5L/QXYqWQUrPQ== X-Google-Smtp-Source: AMsMyM6sO+LOU09ZXjof0uEuD7P3wpQStynULcyl6LgTFLXcVsWYXWq8MBmKYePZBrMNXMTOfiCISA== X-Received: by 2002:a05:6a00:21c8:b0:52b:ffc0:15e7 with SMTP id t8-20020a056a0021c800b0052bffc015e7mr13710910pfj.29.1666029872934; Mon, 17 Oct 2022 11:04:32 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id h9-20020a656389000000b00458a0649474sm6414850pgv.11.2022.10.17.11.04.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Oct 2022 11:04:32 -0700 (PDT) Date: Mon, 17 Oct 2022 18:04:28 +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 Mon, Oct 17, 2022, Peter Gonda wrote: > On Thu, Oct 6, 2022 at 12:25 PM Sean Christopherson wrote: > > And with that, I believe sev_vm_create() can go away entirely and the SEV encryption > > stuff can be handled via a new vm_guest_mode. ____vm_create() already has a gross > > __x86_64__ hook that we can tweak, e.g. > > > > diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c > > index 54b8d8825f5d..2d6cbca2c01a 100644 > > --- a/tools/testing/selftests/kvm/lib/kvm_util.c > > +++ b/tools/testing/selftests/kvm/lib/kvm_util.c > > @@ -238,9 +238,10 @@ struct kvm_vm *____vm_create(enum vm_guest_mode mode, uint64_t nr_pages) > > case VM_MODE_P36V47_16K: > > vm->pgtable_levels = 3; > > break; > > + case VM_MODE_PXXV48_4K_SEV: > > case VM_MODE_PXXV48_4K: > > #ifdef __x86_64__ > > - kvm_get_cpu_address_width(&vm->pa_bits, &vm->va_bits); > > + kvm_init_vm_address_properties(vm); > > /* > > * Ignore KVM support for 5-level paging (vm->va_bits == 57), > > * it doesn't take effect unless a CR4.LA57 is set, which it > > > > Then kvm_init_vm_address_properties() can pivot on vm->mode to deal with SEV > > specific stuff. ... > This refactor sounds good, working on this with a few changes. > > Instead of kvm_init_vm_address_properties() as you suggested I've added this: > > @@ -272,6 +275,8 @@ struct kvm_vm *____vm_create(enum vm_guest_mode > mode, uint64_t nr_pages) > vm->type = KVM_VM_TYPE_ARM_IPA_SIZE(vm->pa_bits); > #endif > > + kvm_init_vm_arch(vm); Why? I'm not necessarily opposed to adding kvm_init_vm_arch(), but since x86 "needs" a dedicated hook to unpack the mode, why not piggyback that one? > + > vm_open(vm); > > /* Limit to VA-bit canonical virtual addresses. */ > > And I need to put kvm_arch_vm_post_create() after the vCPUs are > created because the ordering we need is: KVM_SEV_INIT -> Create vCPUS > -> KVM_SEV_LAUNCH_FINISH. Hrm, that's annoying. Please don't use kvm_arch_vm_post_create() as the name, that's a better fit for what Vishal is doing since the "vm_post_create()" implies that it's called for "all" VM creation paths, where "all" means "everything except barebones VMs". E.g. in Vishal's series, kvm_arch_vm_post_create() can be used to drop the vm_create_irqchip() call in common code. In your case, IIUC the hook will be invoked from __vm_create_with_vcpus(). I'm a little hesitant to have an arch hook for this case since it can't be all-or-nothing (again, ignoring barebones VMs). If a "finalize" arch hook is added, then arguably tests that do __vm_create() and manually add vCPUs should call the arch hook, i.e. we'd be adding maintenance burden to tests that in all likelihood don't care about SEV and never will. It's somewhat unfortunate, but dedicated vm_sev_create_with_one_vcpu() and and vm_sev_create_with_vcpus() wrappers is probably the least awful solution.