qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 5/7] vfio: Introduce VFIO address spaces


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [PATCH v6 5/7] vfio: Introduce VFIO address spaces
Date: Sat, 24 May 2014 13:12:02 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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 <address@hidden>
>>>>>>
>>>>>> 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 <address@hidden>
>>>>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>>>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]