From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F37CD202E5CFF for ; Fri, 20 Oct 2017 08:14:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F201F883C5; Fri, 20 Oct 2017 15:18:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F201F883C5 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-150.rdu2.redhat.com [10.10.120.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1972E5D9C1; Fri, 20 Oct 2017 15:18:36 +0000 (UTC) To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm References: <20171019192141.4782-1-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <67538bc0-93b3-38d1-893d-cdfea242f18a@redhat.com> Date: Fri, 20 Oct 2017 17:18:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 20 Oct 2017 15:18:38 +0000 (UTC) Subject: Re: [PATCH] EmbeddedPkg/DtPlatformDxe: remove /chosen/stdout-path on GOP registration X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:14:59 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/20/17 13:40, Ard Biesheuvel wrote: > I think the best way forward is to implement a separate driver with > its own HII form, that removes /chosen/stdout-path and uninstalls the > SPCR table if either or both are present. I couldn't figure out how to > uninstall a ACPI table though, so I may need to move the SPCR > installation into that driver as well. In general it's best to consider an ACPI table "owned" by the driver that installs it in the first place. The EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() function (from the UEFI spec) outputs a TableKey parameter, and only that parameter can be used as input to the EFI_ACPI_TABLE_PROTOCOL.UninstallAcpiTable() function (also from the UEFI spec). The PI spec defines EFI_ACPI_SDT_PROTOCOL which has a member function called EFI_ACPI_SDT_PROTOCOL.GetAcpiTable() Using this function, you can iterate over all the tables, investigate each, and even get the TableKey for uninstallation. (See the function's specification itself.) So, if you are willing to "go PI", then independent uninstallation is possible. But, IMO, the unclear ownership of any table can lead to a mess down the road. In edk2, EFI_ACPI_SDT_PROTOCOL is available from MdeModulePkg/Universal/Acpi/AcpiTableDxe if gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol is TRUE. For one example, OVMF set the PCD in commit 259d87146b07 ("OvmfPkg: Modify FDF/DSC files for RamDiskDxe's adding NFIT report feature", 2016-04-19). Thanks! Laszlo