From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Brijesh Singh <brijesh.singh@amd.com>,
"Dong, Eric" <eric.dong@intel.com>,
"Justen, Jordan L" <jordan.l.justen@intel.com>,
"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [PATCH 00/10] MdeModulePkg, OvmfPkg: unmap DMA buffers at ExitBootServices
Date: Fri, 8 Sep 2017 07:28:08 +0000 [thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503A9A9954@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20170907224116.895-1-lersek@redhat.com>
Patch 1~3 reviewed-by: Jiewen.yao@intel.com
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Friday, September 8, 2017 6:41 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Brijesh Singh
> <brijesh.singh@amd.com>; Dong, Eric <eric.dong@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Zeng,
> Star <star.zeng@intel.com>
> Subject: [PATCH 00/10] MdeModulePkg, OvmfPkg: unmap DMA buffers at
> ExitBootServices
>
> Repo: https://github.com/lersek/edk2.git
> Branch: iommu_exit_boot
>
> This series is the result of the discussion under
>
> [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.
>
> Patches 01 through 03 clean up the AtaAtapiPassThru driver in
> MdeModulePkg a little bit, because at present, (a) it unmaps the buffers
> and disables BMDMA in the wrong order in its DriverBindingStop()
> function, (b) it doesn't abort pending DMA at ExitBootServices().
>
> This subset can be treated separately from the rest of the series, but I
> thought they belonged loosely together (given that AtaAtapiPassThru is
> used on QEMU's Q35 machine type).
>
> Patches 04 through 07 remove
> VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer()
> calls from the VirtIo drivers' ExitBootServices() handlers.
>
> (The conversion of VirtioNetDxe to device addresses is still in progress
> -- Brijesh, when you submit v2 of that, under this approach, there is no
> need to change VirtioNetExitBoot() relative to current upstream, and you
> can use VirtioOperationBusMasterRead to map outgoing packets.)
>
> Patches 08 through 10 make OvmfPkg/IoMmuDxe track all mappings, and
> unmap all mappings (Read, Write, CommonBuffer) that are in effect when
> ExitBootServices() is called. It is ensured that PCI and VirtIo drivers
> abort pending DMA first, and IoMmuDxe clean up the mappings last.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Star Zeng <star.zeng@intel.com>
>
> Thanks
> Laszlo
>
> Laszlo Ersek (10):
> MdeModulePkg/AtaAtapiPassThru: cache EnabledPciAttributes
> MdeModulePkg/AtaAtapiPassThru: unmap DMA buffers after disabling BM
> DMA
> MdeModulePkg/AtaAtapiPassThru: disable the device at
> ExitBootServices()
> OvmfPkg/VirtioBlkDxe: don't unmap VRING at ExitBootServices()
> OvmfPkg/VirtioGpuDxe: don't unmap VRING & BackingStore at
> ExitBootServices
> OvmfPkg/VirtioRngDxe: don't unmap VRING at ExitBootServices()
> OvmfPkg/VirtioScsiDxe: don't unmap VRING at ExitBootServices()
> OvmfPkg/IoMmuDxe: track all mappings
> OvmfPkg/IoMmuDxe: generalize IoMmuUnmap() to IoMmuUnmapWorker()
> OvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices()
>
> MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 103 +++++---
> MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 7 +
> OvmfPkg/IoMmuDxe/AmdSevIoMmu.c | 246
> +++++++++++++++++---
> OvmfPkg/VirtioBlkDxe/VirtioBlk.c | 7 +-
> OvmfPkg/VirtioGpuDxe/Commands.c | 23 +-
> OvmfPkg/VirtioRngDxe/VirtioRng.c | 7 +-
> OvmfPkg/VirtioScsiDxe/VirtioScsi.c | 7 +-
> 7 files changed, 299 insertions(+), 101 deletions(-)
>
> --
> 2.14.1.3.gb7cf6e02401b
next prev parent reply other threads:[~2017-09-08 7:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 22:41 [PATCH 00/10] MdeModulePkg, OvmfPkg: unmap DMA buffers at ExitBootServices Laszlo Ersek
2017-09-07 22:41 ` [PATCH 01/10] MdeModulePkg/AtaAtapiPassThru: cache EnabledPciAttributes Laszlo Ersek
2017-09-07 22:41 ` [PATCH 02/10] MdeModulePkg/AtaAtapiPassThru: unmap DMA buffers after disabling BM DMA Laszlo Ersek
2017-09-07 22:41 ` [PATCH 03/10] MdeModulePkg/AtaAtapiPassThru: disable the device at ExitBootServices() Laszlo Ersek
2017-10-25 15:26 ` Laszlo Ersek
2017-10-25 20:11 ` Ard Biesheuvel
2017-10-26 5:08 ` Zeng, Star
2017-10-26 14:09 ` Laszlo Ersek
2017-10-26 14:12 ` Ard Biesheuvel
2017-09-07 22:41 ` [PATCH 04/10] OvmfPkg/VirtioBlkDxe: don't unmap VRING " Laszlo Ersek
2017-09-07 22:41 ` [PATCH 05/10] OvmfPkg/VirtioGpuDxe: don't unmap VRING & BackingStore at ExitBootServices Laszlo Ersek
2017-09-07 22:41 ` [PATCH 06/10] OvmfPkg/VirtioRngDxe: don't unmap VRING at ExitBootServices() Laszlo Ersek
2017-09-07 22:41 ` [PATCH 07/10] OvmfPkg/VirtioScsiDxe: " Laszlo Ersek
2017-09-07 22:41 ` [PATCH 08/10] OvmfPkg/IoMmuDxe: track all mappings Laszlo Ersek
2017-09-07 22:41 ` [PATCH 09/10] OvmfPkg/IoMmuDxe: generalize IoMmuUnmap() to IoMmuUnmapWorker() Laszlo Ersek
2017-09-07 22:41 ` [PATCH 10/10] OvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices() Laszlo Ersek
2017-09-08 7:28 ` Yao, Jiewen [this message]
2017-09-08 8:28 ` [PATCH 00/10] MdeModulePkg, OvmfPkg: unmap DMA buffers at ExitBootServices Yao, Jiewen
2017-09-08 7:29 ` Zeng, Star
2017-09-08 8:53 ` Ard Biesheuvel
2017-09-08 9:48 ` Laszlo Ersek
2017-09-08 11:25 ` Ard Biesheuvel
2017-09-08 15:50 ` Brijesh Singh
2017-09-08 16:00 ` Laszlo Ersek
2017-09-08 18:28 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74D8A39837DF1E4DA445A8C0B3885C503A9A9954@shsmsx102.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox