From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 4A2E221CEB0E4 for ; Thu, 7 Sep 2017 05:08:54 -0700 (PDT) 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 mx1.redhat.com (Postfix) with ESMTPS id 071444ACB3; Thu, 7 Sep 2017 12:11:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 071444ACB3 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-54.rdu2.redhat.com [10.10.120.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id CFF6E65E8D; Thu, 7 Sep 2017 12:11:43 +0000 (UTC) To: "Yao, Jiewen" , "Zeng, Star" , edk2-devel-01 Cc: Brijesh Singh , "Dong, Eric" References: <20170903195449.30261-1-lersek@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B93A125@shsmsx102.ccr.corp.intel.com> <4b24b1eb-362f-3b46-97e2-bdfda53f40c9@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503A9A79BD@shsmsx102.ccr.corp.intel.com> <5f1fdc84-5824-bee2-5a1a-fbd67adf5443@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503A9A7F10@shsmsx102.ccr.corp.intel.com> <12d71f32-9dcf-4f6e-b033-d5f82104caca@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503A9A852C@shsmsx102.ccr.corp.intel.com> <24d66e81-336e-3924-8045-4749d98e2fbb@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503A9A8EE2@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <0f8dd474-f594-088a-cc6c-e2b82810e4c1@redhat.com> Date: Thu, 7 Sep 2017 14:11:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9A8EE2@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 07 Sep 2017 12:11:45 +0000 (UTC) Subject: Re: [PATCH 0/4] MdeModulePkg: some PCI HC drivers: unmap common buffers at ExitBootServices() 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: Thu, 07 Sep 2017 12:08:54 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/07/17 06:34, Yao, Jiewen wrote: > Thanks. > It seems the discussion becomes too long. I try to make it short. > > > 1) As long as we use same mechanism to handle both common buffer and read/write buffer. I have no concern at all. :) > > > 2) I am sorry that I do not have an immediate answer for your question on event handling in ExitBootServices. > Although it seems tricky, I believe it works. Can you have a try? > > > 3) Looking at the code (DxeMain.c), I have another idea for your consideration only. > > // > // Notify other drivers that we are exiting boot services. > // > CoreNotifySignalList (&gEfiEventExitBootServicesGuid); > > // > // Report that ExitBootServices() has been called > // > REPORT_STATUS_CODE ( > EFI_PROGRESS_CODE, > (EFI_SOFTWARE_EFI_BOOT_SERVICE | EFI_SW_BS_PC_EXIT_BOOT_SERVICES) > ); > > The cleanup driver may register a report status code handle to do the cleanup. :) > > We already have such example in MdeModulePkg\Universal\Acpi\FirmwarePerformanceDataTableDxe\ FirmwarePerformanceDxe.c. > FpdtStatusCodeListenerDxe() > > } else if (Value == (EFI_SOFTWARE_EFI_BOOT_SERVICE | EFI_SW_BS_PC_EXIT_BOOT_SERVICES)) { > ...... > > The requirement will become: If a platform wants to add cleanup, it must use a real report status code library. I think I prefer option #2; it presents fewer requirements for the platform. In addition: I've just realized that we don't need the UEFI spec to promise us that option #2 works. We only have to care whether it works in edk2. The reason is that EDKII_IOMMU_PROTOCOL is *already* edk2-specific; it is a platform (DXE) driver, not a UEFI driver. In other words, we would use option #2 only inside edk2. So, I'll try option #2. Thanks! Laszlo