OvmfPkg/IoMmuDxe: track all mappings
OvmfPkg/IoMmuDxe: track all mappings

The "mRecycledMapInfos" list implements an internal pool of unused
MAP_INFO structures between the IoMmuUnmap() and IoMmuMap() functions. The
original goal was to allow IoMmuUnmap() to tear down CommonBuffer mappings
without releasing any memory: IoMmuUnmap() would recycle the MAP_INFO
structure to the list, and IoMmuMap() would always check the list first,
before allocating a brand new MAP_INFO structure.

In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it
unmaps all existent bus master operations (CommonBuffer, Read, Write) at
ExitBootServices(), strictly after the individual device drivers abort
pending DMA on the devices they manage, in their own ExitBootServices()
notification functions.

For this, rename and repurpose the list to track all live mappings.

This means that IoMmuUnmap() will always release a MAP_INFO structure
(even when cleaning up a CommonBuffer operation). That's fine (for now),
because device drivers are no longer expected to call Unmap() in their
ExitBootServices() notification functions.

In theory, we could also move the allocation and freeing of the stash
buffer from IoMmuAllocateBuffer() and IoMmuFreeBuffer(), respectively, to
IoMmuMap() and IoMmuUnmap(). However, this would require allocating and
freeing a stash buffer in *both* IoMmuMap() and IoMmuUnmap(), as
IoMmuMap() performs in-place decryption for CommonBuffer operations, and
IoMmuUnmap() performs in-place encryption for the same.

By keeping the stash buffer allocation as-is, not only do we keep the code
almost fully undisturbed, but

- we also continue to guarantee that IoMmuUnmap() succeeds: allocating a
  stash buffer in IoMmuUnmap(), for in-place encryption after a
  CommonBuffer operation, could fail;

- we also keep IoMmuUnmap() largely reusable for ExitBootServices()
  callback context: allocating a stash buffer in IoMmuUnmap() would simply
  be forbidden in that context.

Cc: Ard Biesheuvel <66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org>
Cc: Brijesh Singh <6c1ba716601dd19ee463759bfdaf6de1e69b2b21@amd.com>
Cc: Jiewen Yao <364a90bfebd1f362ebb7b48e4bf8ec010adef203@intel.com>
Cc: Jordan Justen <a79006884ba9cf5f4f7fcbb92a15b208780d8c97@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com>
Reviewed-by: Jiewen Yao <364a90bfebd1f362ebb7b48e4bf8ec010adef203@intel.com>
Reviewed-by: Ard Biesheuvel <66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org>
Reviewed-by: Brijesh Singh <6c1ba716601dd19ee463759bfdaf6de1e69b2b21@amd.com>
Tested-by: Brijesh Singh <6c1ba716601dd19ee463759bfdaf6de1e69b2b21@amd.com>

MattDevo/edk2,MattDevo/edk2,MattDevo/edk2,MattDevo/edk2,MattDevo/edk2,MattDevo/edk2,MattDevo/edk2,MattDevo/edk2