Re: [Qemu-devel] [PATCH v7 1/4] spapr_iommu: Make in-kernel TCE table optional

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2014-06-06 at 01:36 +0200, Alexander Graf wrote:
> 
> It would be nicer if the guest had full control over the virtual
> address range of a PCI device.

It does ... within a HW window which can be different between P7 and
P8. 

On P7 all PEs on a PHB share a single DMA address space that gets sliced
up, I won't get into details on what kind of slices are available,
suffice to say we provide a single smallish window in 32-bit space for
each PE and the guest controls the 4k TCEs in there.

On P8, each PE has its own DMA address space which has 2 wnidows, one at
0 and one at 0x0800_0000_0000_0000.

By default we configure the 0 window for 32-bit/4K TCE remapping (we set
it to 2G window) for compatibility with existing PAPR expectations.

The high window is used in the host as a bypass. We disable TCEs and use
a direct mapping to physical memory through it instead to allow the host
drivers that are 64-bit DMA capable to have the fastest possible access
to memory.

When we pass-through a device today we disable that second window for
obvious reasons.

With Alexey patches, we'll be able to control it which will in turn
allow us to implement the PAPR "DDW" extension which allows the guest to
populate that second window. Typically the guest will use it to create a
full mapping of its entire address space in 64-bit space using the
largest possible TCE size (whose size is constrained by the page size
used to back the guest memory).

Here too, within those windows, the guest has control of the mappings.

Cheers,
Ben.