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.97455.1673329842334606793 for ; Mon, 09 Jan 2023 21:50:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XIZWieZx; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673329841; 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=8xlxfcP1y5CyncRxUpBbuhL2fP8qoqMMJIzQlKqa4xU=; b=XIZWieZxekBaZ6eN5jZk2L74AWSB5D8JnR7v2XjrUjlHykKbDet2WBib0xw0rwyEbxLDg2 pa9xVO5uc/NuHWB1KotK2n4ULSjMKNYY2hq2kVyfvJhWBbL++vaabUlwYnZEcB86fkn9rY O+Osou+bts3qoJRZuVoG428kK48JyOA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-600-zw0jcwqdOHueZ_jbnKJEoA-1; Tue, 10 Jan 2023 00:50:37 -0500 X-MC-Unique: zw0jcwqdOHueZ_jbnKJEoA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A8FC0858F0E; Tue, 10 Jan 2023 05:50:36 +0000 (UTC) Received: from [10.39.192.22] (unknown [10.39.192.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FEF01121314; Tue, 10 Jan 2023 05:50:35 +0000 (UTC) Message-ID: Date: Tue, 10 Jan 2023 06:50:33 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH V2 5/6] OvmfPkg/AcpiPlatformDxe: Refactor QemuAcpiTableNotifyProtocol To: devel@edk2.groups.io, min.m.xu@intel.com Cc: Erdem Aktas , James Bottomley , Jiewen Yao , Gerd Hoffmann , Tom Lendacky References: <20230109135917.1752-1-min.m.xu@intel.com> <20230109135917.1752-6-min.m.xu@intel.com> From: "Laszlo Ersek" In-Reply-To: <20230109135917.1752-6-min.m.xu@intel.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Min, On 1/9/23 14:59, Min Xu wrote: > From: Min M Xu > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237 > > Commit 9fdc70af6ba8 install the QemuAcpiTableNotifyProtocol at a > wrong positioin. It should be called before TransferS3ContextToBootScript > because TransferS3ContextToBootScript is the last operation in > InstallQemuFwCfgTables(). Another error is that we should check the > returned value after installing the QemuAcpiTableNotifyProtocol. > > This patch refactors the installation and error handling of > QemuAcpiTableNotifyProtocol in InstallQemuFwCfgTables (). > > Cc: Laszlo Ersek > Cc: Erdem Aktas > Cc: James Bottomley > Cc: Jiewen Yao > Cc: Gerd Hoffmann > Cc: Tom Lendacky > Reported-by: Laszlo Ersek > Signed-off-by: Min Xu > --- > OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 36 ++++++++++++++++--------- > 1 file changed, 24 insertions(+), 12 deletions(-) > > diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c > index f27a95957f47..14ae13055a30 100644 > --- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c > +++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c > @@ -1249,6 +1249,20 @@ InstallQemuFwCfgTables ( > } > } > > + // > + // Install a protocol to notify that the ACPI table provided by Qemu is > + // ready. > + // > + Status = gBS->InstallProtocolInterface ( > + &QemuAcpiHandle, > + &gQemuAcpiTableNotifyProtocolGuid, > + EFI_NATIVE_INTERFACE, > + NULL > + ); > + if (EFI_ERROR (Status)) { > + goto UninstallAcpiTables; > + } > + > // > // Translating the condensed QEMU_LOADER_WRITE_POINTER commands to ACPI S3 > // Boot Script opcodes has to be the last operation in this function, because > @@ -1257,7 +1271,7 @@ InstallQemuFwCfgTables ( > if (S3Context != NULL) { > Status = TransferS3ContextToBootScript (S3Context); > if (EFI_ERROR (Status)) { > - goto UninstallAcpiTables; > + goto UninstallQemuAcpiTableNotifyProtocol; > } > > // > @@ -1268,6 +1282,15 @@ InstallQemuFwCfgTables ( > > DEBUG ((DEBUG_INFO, "%a: installed %d tables\n", __FUNCTION__, Installed)); > > +UninstallQemuAcpiTableNotifyProtocol: > + if (EFI_ERROR (Status)) { > + gBS->UninstallProtocolInterface ( > + QemuAcpiHandle, > + &gQemuAcpiTableNotifyProtocolGuid, > + NULL > + ); > + } > + > UninstallAcpiTables: > if (EFI_ERROR (Status)) { > // > @@ -1277,17 +1300,6 @@ UninstallAcpiTables: > --Installed; > AcpiProtocol->UninstallAcpiTable (AcpiProtocol, InstalledKey[Installed]); > } > - } else { > - // > - // Install a protocol to notify that the ACPI table provided by Qemu is > - // ready. > - // > - gBS->InstallProtocolInterface ( > - &QemuAcpiHandle, > - &gQemuAcpiTableNotifyProtocolGuid, > - EFI_NATIVE_INTERFACE, > - NULL > - ); > } > > for (SeenPointerEntry = OrderedCollectionMin (SeenPointers); Previously, I wrote: > In fact, I request that you *not* set QemuAcpiHandle to NULL at the > top of the function. Letting *only* InstallProtocolInterface() set it, > upon success, is safe, as long as you use the pattern shown above. That was wrong. When I wrote that, I forgot that, for EFI_BOOT_SERVICES.InstallProtocolInterface(), the "Handle" parameter is "IN OUT", not just OUT. In other words, we state that we want a new handle by setting the Handle to NULL on input. My comment above missed that, I'm sorry. So, I think this patch is good. I do have small request though. Please bear with me: - in patch #3, can you move the "QemuAcpiHandle = NULL" assignment right above the gBS->InstallProtocolInterface() call? - and in patch #5 (i.e., here), can you please *keep* the "QemuAcpiHandle = NULL" assignment together with the gBS->InstallProtocolInterface() call that is being moved? Because, you are right that we need to set QemuAcpiHandle to NULL before we call InstallProtocolInterface(); however, I'd like to prevent the function from making the impression that we depend on "initializing" QemuAcpiHandle like that. Sorry about the churn! Thanks, Laszlo