On 05/23/2014 10:05 PM, Alexander Graf wrote: > > On 23.05.14 14:03, Alexey Kardashevskiy wrote: >> On 05/23/2014 09:28 PM, Alexander Graf wrote: >>> On 23.05.14 06:59, Alexey Kardashevskiy wrote: >>>> From: David Gibson <da...@gibson.dropbear.id.au> >>>> >>>> The only model so far supported for VFIO passthrough devices is the model >>>> usually used on x86, where all of the guest's RAM is mapped into the >>>> (host) IOMMU and there is no IOMMU visible in the guest. >>>> >>>> This patch begins to relax this model, introducing the notion of a >>>> VFIOAddressSpace. This represents a logical DMA address space which will >>>> be visible to one or more VFIO devices by appropriate mapping in the >>>> (host) >>>> IOMMU. Thus the currently global list of containers becomes local to >>>> a VFIOAddressSpace, and we verify that we don't attempt to add a VFIO >>>> group to multiple address spaces. >>>> >>>> For now, only one VFIOAddressSpace is created and used, corresponding to >>>> main system memory, that will change in future patches. >>>> >>>> Signed-off-by: David Gibson <da...@gibson.dropbear.id.au> >>>> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru> >>> Don't we already have a DMA address space in the PCI bus? We could just use >>> that one instead, no? >> I do not know about x86, but for spapr that VFIOAddressSpace is nothing but >> wrapper around an AddressSpace from the SPAPR PHB. > > So why do we need that wrapper? Can't we just use the PHB's AddressSpace?
> There's a good chance I'm not grasping something here :). We cannot attach VFIO containers (aka "groups" or "PEs" for spapr) to AddressSpace, there is nothing like that in AddressSpace/MemoryRegion API as this container thing is local to VFIO. -- Alexey
