[PATCH] Xen-SWIOTLB v0.8.6 used for Xen PCI pass through for PV guests.

From: Konrad Rzeszutek Wilk
Date: Tue Jul 27 2010 - 13:20:18 EST

Changes since last posting [v0.8.3 (http://lkml.org/lkml/2010/6/22/310)]:
- Coalesced the Xen-SWIOTLB set of patches in one patch.
- Moved the swiotlb-xen.c to drivers/xen.
- Added Ack's, Cc's, as appropriate.

This patchset:

These nine patches lay the groundwork for Xen Paravirtualized (PV)
domains to access PCI pass-through devices (with and without an hardware
IOMMU) These patches utilize the SWIOTLB library modifications

The end user of this are:
- The Xen PCI frontend and Xen PCI [1] which require a DMA API "backend"
that understands Xen's MMU. This allows the PV domains to use PCI devices.
The use case is for machines with and without hardware IOMMU. Without an
hardware IOMMU you have a potential security hole wherin a guest domain
can use the hardware to map pages outside its memory range and slurp
pages up. As such, this is more restricted to a Priviliged PV domain,
aka - device driver domain (similar to Qubes but a poor-man mechanism [2]).
- Xen PV domain 0 support. Without this domain 0 is incapable of using any
PCI devices.

This patch-set is split in two groups. The first alter the Xen components,
while the second introduces the SWIOTLB-Xen.

The Xen components patches consist of:

xen: Allow unprivileged Xen domains to create iomap pages
xen: Rename the balloon lock
xen: Add xen_create_contiguous_region
xen: use _PAGE_IOMAP in ioremap to do machine mappings
vmap: add flag to allow lazy unmap to be disabled at runtime
xen/mmu: inhibit vmap aliases rather than trying to clear them out

which alter the Xen MMU, which by default utilizes a layer of indirection
wherein the PFN is translated to the Machine Frame Number (MFN) and vice-versa.
This is required to "fool" the guest in thinking its memory starts at PFN 0 and
goes up to the available amount. While in the background, PFN 0 might as well be
MFN 1048576 (4GB).

For PCI/DMA API calls (ioremap, pci_map_page, etc) having a PFN != MFN is
not too good, so two new mechanisms are introduced:
a). For PTEs which manipulate the PCI/DMA pages the PFN == MFN. This is done
via utilizing the _PAGE_IOMAP flag to distinguish the PTE as an IO type.
b). Allow a mechanism to "swizzle" the MFN's under a PFN to be under a certain
bus width (say 32). This allows us to provide a mechanism for the
SWIOTLB Xen to allocate memory for its pool that will be guaranteed to be
under the 4GB mark.

We also introduce a mechanism to inhibit vmap aliases as we need to clear the
vmap's but might be doing this in atomic state.

The SWIOTLB-Xen adds a library that is only used if the machine is detected
to be running under Xen. It utilizes the SWIOTLB library bookkeeping functions
(swiotlb_tbl_*) and only deals with the virtual to [physical, bus] (and vice-versa)
address translations.

The diffstat:

arch/x86/include/asm/xen/page.h | 8 +-
arch/x86/include/asm/xen/swiotlb-xen.h | 14 +
arch/x86/kernel/pci-dma.c | 7 +-
arch/x86/xen/Makefile | 1 +
arch/x86/xen/enlighten.c | 4 +
arch/x86/xen/mmu.c | 293 ++++++++++++++++++-
arch/x86/xen/pci-swiotlb-xen.c | 58 ++++
drivers/xen/Kconfig | 4 +
drivers/xen/Makefile | 3 +-
drivers/xen/balloon.c | 15 +-
drivers/xen/swiotlb-xen.c | 515 ++++++++++++++++++++++++++++++++
include/linux/vmalloc.h | 2 +
include/xen/interface/memory.h | 50 +++
include/xen/swiotlb-xen.h | 65 ++++
include/xen/xen-ops.h | 6 +
mm/vmalloc.c | 4 +
16 files changed, 1024 insertions(+), 25 deletions(-)

The patchset that this depends on (which is in linux-next), is:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git stable/swiotlb-0.8.3
This patcheset (Xen-SWIOTLB) is available at:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git devel/xen-swiotlb-0.8.6
And the customer of this (Xen PCI front):
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/xen-pcifront-0.3
The tree with all of this on top of v2.6.35-rc6:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/merge.2.6.35-rc6.t2

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/