On 05/24/2014 07:15 AM, Alexander Graf wrote: > > On 23.05.14 18:16, Alexey Kardashevskiy wrote: >> 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. > > Ok, please explain how this AddressSpace is different from the VFIO > device's parent's IOMMU DMA AddressSpace and why we need it.
Nothing special. We attach group to address space by trying to add a group to every container in that address space. If it fails, we create a new container, put new group into it and attach container to the VFIO address space. The point here is we attach group to address space. We could still have a global containers list and when adding a group, loop through the global list of containers and look at the AS they are attached to but the logical structure AS->container->group->device remains the same. Honestly, I would never come up with the patch like this myself (I am too stupid for that :) ) but as it is here - I find it quite logical. -- Alexey
