From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoVTj-0004L3-0g for qemu-devel@nongnu.org; Sun, 25 May 2014 06:16:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WoVTe-0003os-46 for qemu-devel@nongnu.org; Sun, 25 May 2014 06:16:30 -0400 Message-ID: <5381C2F4.8040402@suse.de> Date: Sun, 25 May 2014 12:16:20 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1400821160-25258-1-git-send-email-aik@ozlabs.ru> <1400821160-25258-6-git-send-email-aik@ozlabs.ru> <537F30C7.3010704@suse.de> <537F392B.7020209@ozlabs.ru> <537F3972.9080907@suse.de> <537F7473.6000200@ozlabs.ru> <537FBA8A.6020704@suse.de> <53800E02.6050400@ozlabs.ru> In-Reply-To: <53800E02.6050400@ozlabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 5/7] vfio: Introduce VFIO address spaces List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy , qemu-devel@nongnu.org Cc: Alex Williamson , qemu-ppc@nongnu.org, David Gibson On 24.05.14 05:12, Alexey Kardashevskiy wrote: > 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 >>>>>>> >>>>>>> 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 >>>>>>> Signed-off-by: Alexey Kardashevskiy >>>>>> 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. I honestly still have no idea what all of this is doing and why we can't model it with PCI buses' IOMMU ASs. Alex, do you grasp it? Alex