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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 4AAF3C433DB for ; Mon, 18 Jan 2021 19:48:32 +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 A5E2522C9D for ; Mon, 18 Jan 2021 19:48:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5E2522C9D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36112 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1aVq-000429-Cd for qemu-devel@archiver.kernel.org; Mon, 18 Jan 2021 14:48:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1aVD-0003Uq-Fj for qemu-devel@nongnu.org; Mon, 18 Jan 2021 14:47:51 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54166) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1l1aVB-0001Hn-F4 for qemu-devel@nongnu.org; Mon, 18 Jan 2021 14:47:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610999268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MhZad9UHyV5bfJ/NZreQvSZ/wofQuPMMkJX3iQbf4II=; b=KCV59UVi1zd4jnqhPxBvW/GF1UvGylUWYehk0178rRrAzs0+/1PzYrQdkGPKpydXgw0ePj XV3SN2nzoHjjwk0ECVOpG7U9Y4hmOO+4XDcHoXWLNVuls5BwbjfJrp5n4a/IH8kB76Z0Yi eht9jlR8eBH55sWsfWsUUSdO3Jvj3Hw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-73-v6w6ETmROtyji68K0QykFA-1; Mon, 18 Jan 2021 14:47:46 -0500 X-MC-Unique: v6w6ETmROtyji68K0QykFA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9F86D1005504; Mon, 18 Jan 2021 19:47:43 +0000 (UTC) Received: from work-vm (ovpn-115-197.ams2.redhat.com [10.36.115.197]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DE2D660C9C; Mon, 18 Jan 2021 19:47:32 +0000 (UTC) Date: Mon, 18 Jan 2021 19:47:30 +0000 From: "Dr. David Alan Gilbert" To: David Gibson Subject: Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag Message-ID: <20210118194730.GH9899@work-vm> References: <20210113235811.1909610-1-david@gibson.dropbear.id.au> <20210113235811.1909610-8-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210113235811.1909610-8-david@gibson.dropbear.id.au> User-Agent: Mutt/1.14.6 (2020-07-11) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Received-SPF: pass client-ip=216.205.24.124; envelope-from=dgilbert@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.175, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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, mdroth@linux.vnet.ibm.com, pasic@linux.ibm.com, borntraeger@de.ibm.com, andi.kleen@intel.com, thuth@redhat.com, Eduardo Habkost , Richard Henderson , Greg Kurz , 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" * David Gibson (david@gibson.dropbear.id.au) 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. You may find you need to define 'ready' and the answer might be a bit variable; for example, on SEV there's a setup bit and then you may end up doing an attestation and receiving some data before you actaully let the guest execute code. Is it ready before it's received the attestation response or only when it can run code? Is a Power or 390 machine 'ready' before it's executed the magic instruction to enter the confidential mode? Dave > 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; > -- > 2.29.2 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK