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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58EA6C433E0 for ; Thu, 14 Jan 2021 08:56:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DCE18239EF for ; Thu, 14 Jan 2021 08:56:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCE18239EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kaod.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzyQt-0003i4-Sc for qemu-devel@archiver.kernel.org; Thu, 14 Jan 2021 03:56:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzyPV-0002qa-EK for qemu-devel@nongnu.org; Thu, 14 Jan 2021 03:55:17 -0500 Received: from 3.mo52.mail-out.ovh.net ([178.33.254.192]:40844) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzyPT-000493-Aj for qemu-devel@nongnu.org; Thu, 14 Jan 2021 03:55:17 -0500 Received: from mxplan5.mail.ovh.net (unknown [10.109.146.173]) by mo52.mail-out.ovh.net (Postfix) with ESMTPS id 3CA46230150; Thu, 14 Jan 2021 09:55:10 +0100 (CET) Received: from kaod.org (37.59.142.100) by DAG8EX1.mxp5.local (172.16.2.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 14 Jan 2021 09:55:09 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-100R00352f46628-57d0-46e2-9de7-07363bd0adac, 0A7C53367AF3A9CD096E542ECC3C8B2C2D100868) smtp.auth=groug@kaod.org X-OVh-ClientIp: 82.253.208.248 Date: Thu, 14 Jan 2021 09:55:08 +0100 From: Greg Kurz To: David Gibson Subject: Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag Message-ID: <20210114095508.3ef1db7e@bahia.lan> In-Reply-To: <20210113235811.1909610-8-david@gibson.dropbear.id.au> References: <20210113235811.1909610-1-david@gibson.dropbear.id.au> <20210113235811.1909610-8-david@gibson.dropbear.id.au> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [37.59.142.100] X-ClientProxiedBy: DAG4EX1.mxp5.local (172.16.2.31) To DAG8EX1.mxp5.local (172.16.2.71) X-Ovh-Tracer-GUID: 1b4eaa1f-9249-4295-af14-40e7aee9315b X-Ovh-Tracer-Id: 499336611335149980 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedukedrtdeggdduvdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhfogggtgfhisehtjeertdertddvnecuhfhrohhmpefirhgvghcumfhurhiiuceoghhrohhugheskhgrohgurdhorhhgqeenucggtffrrghtthgvrhhnpeefuddtieejjeevheekieeltefgleetkeetheettdeifeffvefhffelffdtfeeljeenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddruddttdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnhehrdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepghhrohhugheskhgrohgurdhorhhgpdhrtghpthhtoheprghnughirdhklhgvvghnsehinhhtvghlrdgtohhm Received-SPF: pass client-ip=178.33.254.192; envelope-from=groug@kaod.org; helo=3.mo52.mail-out.ovh.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pair@us.ibm.com, cohuck@redhat.com, brijesh.singh@amd.com, kvm@vger.kernel.org, David Hildenbrand , qemu-devel@nongnu.org, frankja@linux.ibm.com, pragyansri.pathi@intel.com, mst@redhat.com, pasic@linux.ibm.com, borntraeger@de.ibm.com, andi.kleen@intel.com, thuth@redhat.com, Eduardo Habkost , Richard Henderson , dgilbert@redhat.com, qemu-s390x@nongnu.org, jun.nakajima@intel.com, berrange@redhat.com, Marcelo Tosatti , qemu-ppc@nongnu.org, Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 14 Jan 2021 10:58:05 +1100 David Gibson wrote: > The platform specific details of mechanisms for implementing > confidential guest support may require setup at various points during > initialization. Thus, it's not really feasible to have a single cgs > initialization hook, but instead each mechanism needs its own > initialization calls in arch or machine specific code. > > However, to make it harder to have a bug where a mechanism isn't > properly initialized under some circumstances, we want to have a > common place, relatively late in boot, where we verify that cgs has > been initialized if it was requested. > > This patch introduces a ready flag to the ConfidentialGuestSupport > base type to accomplish this, which we verify just before the machine > specific initialization function. > Since this is a strong requirement for any new cgs implementation, I guess it could be advertised a bit more with some extra documentation in the confidential-guest-support.h header file as well. Anyway, Reviewed-by: Greg Kurz Unrelated. I've just spotted mdroth@linux.vnet.ibm.com in the Cc list of this thread, but, as you know, Mike is now working on other topics at AMD :) > Signed-off-by: David Gibson > --- > hw/core/machine.c | 8 ++++++++ > include/exec/confidential-guest-support.h | 2 ++ > target/i386/sev.c | 2 ++ > 3 files changed, 12 insertions(+) > > diff --git a/hw/core/machine.c b/hw/core/machine.c > index 94194ab82d..5a7433332b 100644 > --- a/hw/core/machine.c > +++ b/hw/core/machine.c > @@ -1190,6 +1190,14 @@ void machine_run_board_init(MachineState *machine) > } > > if (machine->cgs) { > + /* > + * Where confidential guest support is initialized depends on > + * the specific mechanism in use. But, we need to make sure > + * it's ready by now. If it isn't, that's a bug in the > + * implementation of that cgs mechanism. > + */ > + assert(machine->cgs->ready); > + > /* > * With confidential guests, the host can't see the real > * contents of RAM, so there's no point in it trying to merge > diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h > index 5f131023ba..bcaf6c9f49 100644 > --- a/include/exec/confidential-guest-support.h > +++ b/include/exec/confidential-guest-support.h > @@ -27,6 +27,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT) > > struct ConfidentialGuestSupport { > Object parent; > + > + bool ready; > }; > > typedef struct ConfidentialGuestSupportClass { > diff --git a/target/i386/sev.c b/target/i386/sev.c > index e2b41ef342..3d94635397 100644 > --- a/target/i386/sev.c > +++ b/target/i386/sev.c > @@ -737,6 +737,8 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp) > qemu_add_machine_init_done_notifier(&sev_machine_done_notify); > qemu_add_vm_change_state_handler(sev_vm_state_change, sev); > > + cgs->ready = true; > + > return 0; > err: > sev_guest = NULL;