From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web08.618.1623166631566156119 for ; Tue, 08 Jun 2021 08:37:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ghd5UDrg; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623166630; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Hfl21X5xor8zruJR5kA53QT1imIa/kGWpD6LriVDmv0=; b=ghd5UDrgwXH2KqrpFfCF6E+9NXyoqDWskStIqM9pU8W54UjFH9AT25CHz+5TetJBytVqbV 9q7OG04sm4Wdk/dW87WcZEe3EOA0KKYnZBmetR3b03ziyyP6j3TQYPAhLEuu6voVDf5viX UTA3ztN2gbhXUG/s8m+1Hua+LJbmPG0= 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-275-GGeu-I_6O0-TvL7_t_t87g-1; Tue, 08 Jun 2021 11:37:08 -0400 X-MC-Unique: GGeu-I_6O0-TvL7_t_t87g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0A67380574E; Tue, 8 Jun 2021 15:36:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-124.ams2.redhat.com [10.36.112.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DCED6197F9; Tue, 8 Jun 2021 15:36:55 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF To: "Xu, Min M" , "devel@edk2.groups.io" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: "jejb@linux.ibm.com" , Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." References: From: "Laszlo Ersek" Message-ID: Date: Tue, 8 Jun 2021 17:36:54 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/08/21 14:27, Xu, Min M wrote: > On 06/04/2021 12:12 AM, Laszlo wrote: >> But it counts as an absolute disaster nowadays, and should not be revived in >> any platform. If you don't have pflash in TDX guests, just accept that you >> won't have non-volatile variables. And link PlatformFvbLibNull into >> EmuVariableFvbRuntimeDxe. You're going to need a separate >> PlatformBootManagerLib instance anyway. >> > I have a question here, that if PlatformFvbLibNull is linked into EmuVaiableFvRuntimeDxe, > Does it mean it cannot write to the in-RAM variable store? No, that's not the case; PlatformFvbLibNull only turns the hooks (special callbacks) into no-ops; the normal operation of EmuVariableFvbRuntimeDxe is not disrupted. The APIs in the PlatformFvbLib class are PlatformFvbDataRead, PlatformFvbDataWritten, PlatformFvbBlocksErased; they are called at the ends of the functions FvbProtocolEraseBlocks(), FvbProtocolWrite(), FvbProtocolRead(), in "OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c". If the PlatformFvb* APIs do nothing, that's not a problem for EmuVariableFvbRuntimeDxe. (In fact, even in the non-Null instance -- that is, in the EmuVariableFvbLib instance --, the read and erase callbacks are empty; and the write callback only signals an event, at best.) >> (We should have removed EmuVariableFvbRuntimeDxe a long time ago from >> the traditional OVMF platforms, i.e. made pflash a hard requirement, even >> when SMM is not built into the platform -- but whenever I tried that, Jordan >> always shot me down.) >> > I am afraid in TDVF we have to use EmuVariableFvRuntimeDxe to emulate the > in-RAM, as I explained pflash is not part of the *board* in TDX setup. Using EmuVariableFvbRuntimeDxe in the TDVF platform is fine (with the Null hooks, see above), as long as we carefully document the expected / resultant behavior of the UEFI variable services. (This is not a comment on my part on the SB situation, which remains an open question for TDVF, for the time being.) Thanks Laszlo