From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.4740.1642149138483192039 for ; Fri, 14 Jan 2022 00:32:18 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gEv/IqOW; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642149137; 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=D0B0hQIl1o1rw9izrbwm0KIlDMKx4KALRSu9d4875Jo=; b=gEv/IqOWt6Wb6VuoTVxurEutLSXCfI0uRuHAyq2GR2ZAt6jL1wPeh60BkCSMeFH4Yc1bOa sCMLNHd0kUE7VyrJrXajvy+HiG8X1MDmC3/aZ/cyggMBzqC9mcOY/heEnDDdnyhwKCyUwP AdOnRuGWsO9Djs/75iOgepzMJrDWAMY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-518-Vj0nRoEzMXK57DnWujsRkQ-1; Fri, 14 Jan 2022 03:32:14 -0500 X-MC-Unique: Vj0nRoEzMXK57DnWujsRkQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CE77D1019983; Fri, 14 Jan 2022 08:32:12 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7D65378B1B; Fri, 14 Jan 2022 08:32:12 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C2A1318003A2; Fri, 14 Jan 2022 09:32:10 +0100 (CET) Date: Fri, 14 Jan 2022 09:32:10 +0100 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Kinney, Michael D" , Brijesh Singh , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B Message-ID: <20220114083210.uwd3umo7lktdvn7a@sirius.home.kraxel.org> References: <20211216142525.pkaxszwaevlpg4ap@sirius.home.kraxel.org> <20211220121145.aiqcqs6vd2hb2sb4@sirius.home.kraxel.org> <20220103080218.ap7tktgh4fuvw6sf@sirius.home.kraxel.org> <20220110075537.2dxghysjlz5rmwhm@sirius.home.kraxel.org> <20220111092304.2n72req6ocdkqfub@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > I don't see that PEI-less boot is required for that. Sure, when stripping down > > the build and removing all the features which require PEIMs there isn't much > > left to do for the PEI phase. So it makes sense to look into dropping PEI > > altogether. But it's more a "nice to have" > > than a hard requirement, no? > No. I have to say PEI-less boot in Config-B is a hard requirement. I'm still wondering why though. I have not yet seen a reason why config-b can't use the PEI-based boot flow. > > > 4. But a basic version of PlatformInitLib is a good start. > > > > Yes. Having initially only the functions needed by config-b in PlatformInitLib > > is perfectly fine, but this should be a code *move* not a copy. > > > > > During the development and community review, we can understand better > > > what functions should be wrapped into PlatformInitLib. After that > > > PlatformInitLib can be evolved for OvmfPkg/PlatformPei, > > > Bhyve/PlatformPei, XenPlatformPei. > > > > Yes, most likely there are a number of opportunities to reduce code > > duplication in the three PlatformPei variants we have by moving code to the > > (shared) PlatformInitLib. > > > > That can be looked at later. > > So let me summarize the discussion about PlatformInitLib. > 1. PlatformInitLib wraps the common functions in OvmfPkg/PlatformPei. > These common functions covers the memory detection via fw_cfg, pci > init, cmos, (MemDetect.c/Platform.c/Cmos.c). Yes. Everything needed for PEI-less / config-b boot moves to PlatformInitLib. PlatformInitLib is added as dependency to OvmfPkg/PlatformPei, so PlatformPei can call those functions when booting with PEI. PEI-less boot will add PlatformInitLib to SEC (and DXE) instead so the same code can be used then. Not sure how to handle cmos best. Not needed for memory detection on qemu, but cloudhw depends on it so it is back for now. Will cloudhw support tdx too btw? > And PlatformInitLib will > not handle the S3/SMM variants. At least not initially. Maybe later when we move more code to the lib to reduce code duplication in xen/bhyve/qemu PlatformPei variants. > 2. OvmfPkg/PlatformPei will be refactored with PlatformInitLib. The > functions not needed by config-b stay in PlatformPei. > 3. Config-B support PEI-less boot for both legacy guest and td guest. Yes. take care, Gerd