qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [0/14] Preliminary work for IOMMU emulation support (v3)


From: David Gibson
Subject: [Qemu-devel] [0/14] Preliminary work for IOMMU emulation support (v3)
Date: Mon, 31 Oct 2011 17:06:44 +1100

A while back, Eduard - Gabriel Munteanu send a series of patches
implementing support for emulating the AMD IOMMU in conjunction with
qemu emulated PCI devices.  A revised patch series added support for
the Intel IOMMU, and I also send a revised version of this series
which added support for the hypervisor mediated IOMMU on the pseries
machine.

Richard Henderson also weighed in on the discussion, and there's still
a cretain amount to be thrashed out in terms of exactly how to set up
an IOMMU / DMA translation subsystem.

However, really only 2 or 3 patches in any of these series have
contained anything interesting.  The rest of the series has been
converting existing PCI emulated devices to use the new DMA interface
which worked through the IOMMU translation, whatever it was.  While we
keep working out what we want for the guts of the IOMMU support, these
device conversion patches keep bitrotting against updates to the
various device implementations themselves.

Really, regardless of whether we're actually implementing IOMMU
translation, it makes sense that qemu code should distinguish between
when it is really operating in CPU physical addresses and when it is
operating in bus or DMA addresses which might have some kind of
translation into physical addresses.

This series, therefore, begins the conversion of existing PCI device
emulation code to use new (stub) pci dma access functions.  These are,
for now, just defined to be untranslated cpu physical memory accesses,
as before, but has three advantages:

  * It becomes obvious where the code is working with dma addresses,
    so it's easier to grep for what might be affected by an IOMMU or
    other bus address translation.

  * The new stubs take the PCIDevice *, from which any of the various
    suggested IOMMU interfaces should be able to locate the correct
    IOMMU translation context.

  * The new pci_dma_{read,write}() functions have a return value.
    When we do have IOMMU support, translation failures could lead to
    these functions failing, so we want a way to report it.

This series converts all the easy cases.  It doesn't yet handle
devices which have both PCI and non-PCI variants, such as AHCI, OHCI
and ne2k.  Unlike the earlier version of this series, functions using
scatter gather _are_ covered, though.

Changes since v2:
 * Moved the stub functions from pci.c to pci.h, making them inlines
 * Changed the stX/ldX_pci_dma() functions call stX/ldX_phys()
   directly, rather than using pci_dma_rw().  This means that they
   should access the host memory atomically, previously this was an
   unstated and dangerous semantic change.
 * Cleaned up and split out definition of dma_addr_t, DMADirection and
   their use in the scatter/gather code.
 * Added a DMA_ADDR_FMT define for using dma_addr_t values in printf()
   and used this in some of the driver updates.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]