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 62C3721A1099D for ; Mon, 27 Nov 2017 04:25:11 -0800 (PST) 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 1EDF6BDF7; Mon, 27 Nov 2017 12:29:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-232.rdu2.redhat.com [10.10.120.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1D0A45D756; Mon, 27 Nov 2017 12:29:30 +0000 (UTC) To: "Yao, Jiewen" , "Ni, Ruiyu" , Paolo Bonzini Cc: "Dong, Eric" , Ard Biesheuvel , edk2-devel-01 , Dann Frazier , "Zeng, Star" References: <20171026154819.20865-1-lersek@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5BACC0A1@SHSMSX104.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9BABBA@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BACDEC2@SHSMSX104.ccr.corp.intel.com> <831b3082-2554-8196-5f79-d018e6d4ce37@redhat.com> <892BF6B9-3CCC-45DB-8C72-E526130502BE@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503AA2B77C@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <0236afa2-e365-af7a-9374-7fd1ad742c36@redhat.com> Date: Mon, 27 Nov 2017 13:29:30 +0100 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: <74D8A39837DF1E4DA445A8C0B3885C503AA2B77C@shsmsx102.ccr.corp.intel.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.29]); Mon, 27 Nov 2017 12:29:33 +0000 (UTC) Subject: Re: [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA 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: Mon, 27 Nov 2017 12:25:12 -0000 Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Hi Jiewen, On 11/24/17 02:40, Yao, Jiewen wrote: > Maybe, can we revisit the original requirement on why we need disable BME at ExitBootService for OVMF? > > I recall we have lots of discussion at September. It is good to refresh. > > ============================== > [edk2] [PATCH 0/4] MdeModulePkg: some PCI HC drivers: unmap common buffers at ExitBootServices() > https://lists.01.org/pipermail/edk2-devel/2017-September/014099.html > > At ExitBootServices(), PCI and VirtIo drivers should only care about > aborting pending DMA on the devices. Cleaning up PciIo mappings (which > ultimately boil down to IOMMU mappings) for those aborted DMA operations > should be the job of the IOMMU driver. > ============================== > > I think the Driver Writer's Guide recommend to stop the transaction. > But it does not say you must turn off BME. > Clear BME is just one way to meet the recommendation. > Maybe we can figure out other way to halt the controller, or stop DMA transaction? > Such as stop timer event, set device reset/halt register, etc. > I think USB has already done that. > > > On the other hand, I do not think "OVMF does not support S4" is a good justification to add PCD. > Yes, it does not support at this moment. But who knows the status after 3 or 5 years? > I also heard some VMM do support S4 resume Guest. > > > I also recommend to rollback all BME operation at EBS as first step, then go back to see what is best way to I agree that, if the device and the driver offer another way to abort pending DMA, we can use that too. In fact, my very first patch for AtaAtapiPassThru on this topic used AhciReset(): [1] http://mid.mail-archive.com/20170903195449.30261-5-lersek@redhat.com But then you recommended clearing BusMasterEnable: [2] http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503A9A79BD@shsmsx102.ccr.corp.intel.com (The old patch [1] I referenced above also called PciIo->Unmap(). We've since agreed that *that* part of the idea was wrong, so I'm not suggesting to return to PciIo->Unmap().) So, perhaps AhciReset() would be good enough after all, for aborting pending DMA. Thanks, Laszlo >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ni, >> Ruiyu >> Sent: Friday, November 24, 2017 9:04 AM >> To: Paolo Bonzini >> Cc: Dong, Eric ; Ard Biesheuvel >> ; edk2-devel-01 ; Dann >> Frazier ; Laszlo Ersek ; Zeng, Star >> >> Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only >> BM-DMA at ExitBootServices() >> >> Maybe win10 does some optimization in S4 path. >> >> Sent from a small-screen device >> >> 在 2017年11月24日，上午8:01，Paolo Bonzini >> > 写道： >> >> On 23/11/2017 14:08, Laszlo Ersek wrote: >> On 11/23/17 03:20, Ni, Ruiyu wrote: >> I cannot explain precisely why the S4 resume fails. >> I can just guess: Windows might have some assumptions on the BM bit. >> Can we make this configurable on the platform level somehow? >> >> On one hand, I certainly don't want to break Windows 10, even in case >> this issue ultimately turns out to be a Windows 10 bug. >> >> On the other hand, OVMF does not support S4, and disabling BMDMA at >> ExitBootServices() in PCI drivers is specifically what the Driver >> Writers' Guide recommends. Otherwise pending DMA could corrupt OS memory. >> >> S4 can be done by the OS even if firmware says it doesn't support it. >> >> Once hibernation is done, it is merely a "courtesy" for the OSPM to turn >> off the computer using the _S4 ACPI object rather than _S5. >> >> Paolo >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel