From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
"afish@apple.com" <afish@apple.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
Brijesh Singh <brijesh.singh@amd.com>,
Eric Dong <eric.dong@intel.com>,
Jiewen Yao <jiewen.yao@intel.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Star Zeng <star.zeng@intel.com>
Subject: Re: [PATCH 00/10] MdeModulePkg, OvmfPkg: unmap DMA buffers at ExitBootServices
Date: Fri, 8 Sep 2017 09:53:06 +0100 [thread overview]
Message-ID: <CAKv+Gu8PApyBOaz1NQUkwQ98a7G-jo253szRN+9L7xY=MzA=Ag@mail.gmail.com> (raw)
In-Reply-To: <20170907224116.895-1-lersek@redhat.com>
(cc'ing the trinity)
On 7 September 2017 at 23:41, Laszlo Ersek <lersek@redhat.com> wrote:
> 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.
>
The patches look fine to me
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Given that we are now depending on events signalled in an event
handler to be queued after all currently pending events, I think we
need to explicitly agree that this behavior that needs to be
preserved, and documented somewhere, given that the UEFI spec does not
offer this guarantee.
next prev parent reply other threads:[~2017-09-08 8:50 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 ` [PATCH 00/10] MdeModulePkg, OvmfPkg: unmap DMA buffers at ExitBootServices Yao, Jiewen
2017-09-08 8:28 ` Yao, Jiewen
2017-09-08 7:29 ` Zeng, Star
2017-09-08 8:53 ` Ard Biesheuvel [this message]
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='CAKv+Gu8PApyBOaz1NQUkwQ98a7G-jo253szRN+9L7xY=MzA=Ag@mail.gmail.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