From nobody Fri Dec 27 03:42:19 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1504468499183705.741888030629; Sun, 3 Sep 2017 12:54:59 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 9B90421E74928; Sun, 3 Sep 2017 12:52:09 -0700 (PDT) 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 57B2821E2BE36 for ; Sun, 3 Sep 2017 12:52:08 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00D0083F3D; Sun, 3 Sep 2017 19:54:55 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-188.rdu2.redhat.com [10.10.120.188]) by smtp.corp.redhat.com (Postfix) with ESMTP id B5F3B5D75C; Sun, 3 Sep 2017 19:54:53 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 00D0083F3D Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com From: Laszlo Ersek To: edk2-devel-01 Date: Sun, 3 Sep 2017 21:54:46 +0200 Message-Id: <20170903195449.30261-2-lersek@redhat.com> In-Reply-To: <20170903195449.30261-1-lersek@redhat.com> References: <20170903195449.30261-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sun, 03 Sep 2017 19:54:55 +0000 (UTC) Subject: [edk2] [PATCH 1/4] MdeModulePkg/UhciDxe: unmap BM common buffers when exiting boot services 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: , Cc: Eric Dong , Star Zeng MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Section 7.7 Adding the Exit Boot Services feature in Driver Writer's Guide for UEFI 2.3.1 (v1.01) writes, > Examples from the EDK II that use this feature are the PCI device > drivers for USB Host Controllers. Some USB Host Controllers are PCI Bus > Masters that continuously access a memory buffer to poll for operation > requests. Access to this memory buffer by a USB Host Controller may be > required to boot an operation system, but this activity must be > terminated when the OS calls ExitBootServices() . The typical action in > the Exit Boot Services Event for these types of drivers is to disable > the PCI bus master and place the USB Host Controller into a halted > state. UhcExitBootService() already resets the host controller, which causes the host controller to forget about all common buffers configured previously. However, if the system has a component that translates device addresses to system memory addresses (such as an IOMMU), then the translations put in place when the common buffers were originally mapped should also be undone, before handing control to the OS. UhciDxe maps two kinds of common buffers: (1) The Frame List is initially mapped in UhciDriverBindingStart() UhciInitFrameList() and it is unmapped and mapped again, for an unspecified number of times, in Uhci2Reset() UhciDestoryFrameList() UhciInitFrameList() (2) Memory blocks in the USB Host Controller memory pool are first added in UhciDriverBindingStart() UhciAllocateDev() UsbHcInitMemPool() UsbHcAllocMemBlock() and then for an unspecified number of times in UsbHcAllocateMem() UsbHcAllocMemBlock() whenever the pool has to be extended. Both kinds of common buffers are unmapped in the following call tree: UhciDriverBindingStop() UhciCleanDevUp() UhciDestoryFrameList() <- UhciFreeDev() UsbHcFreeMemPool() UsbHcFreeMemBlock() <- The common buffers should be unmapped at ExitBootServices() the same way. In that context however, we must not free memory (because that could alter the UEFI memory map, which is forbidden for ExitBootServices() notification functions). So call PciIo->Unmap() without calling PciIo->FreeBuffer(). Cc: Brijesh Singh Cc: Eric Dong Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c | 25 +++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c b/MdeModulePkg/Bus/Pci/Uhc= iDxe/Uhci.c index 1fcc8b5f320f..cd9407faf22a 100644 --- a/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c +++ b/MdeModulePkg/Bus/Pci/UhciDxe/Uhci.c @@ -1594,7 +1594,9 @@ UhcExitBootService ( VOID *Context ) { - USB_HC_DEV *Uhc; + USB_HC_DEV *Uhc; + USBHC_MEM_POOL *MemPool; + USBHC_MEM_BLOCK *MemBlock; =20 Uhc =3D (USB_HC_DEV *) Context; =20 @@ -1608,6 +1610,27 @@ UhcExitBootService ( // UhciSetRegBit (Uhc->PciIo, USBCMD_OFFSET, USBCMD_HCRESET); gBS->Stall (UHC_ROOT_PORT_RECOVERY_STALL); + + // + // Unmap the frame list. + // + if (Uhc->FrameBase !=3D NULL) { + Uhc->PciIo->Unmap (Uhc->PciIo, Uhc->FrameMapping); + } + + // + // Unmap the memory pool. + // + MemPool =3D Uhc->MemPool; + if (MemPool !=3D NULL) { + for (MemBlock =3D MemPool->Head; + MemBlock !=3D NULL; + MemBlock =3D MemBlock->Next) { + if (MemBlock->BufHost !=3D NULL) { + MemPool->PciIo->Unmap (MemPool->PciIo, MemBlock->Mapping); + } + } + } } =20 /** --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel