[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

From: Kirti Wankhede
Subject: Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support
Date: Fri, 9 Sep 2016 00:18:10 +0530

On 9/8/2016 3:43 AM, Alex Williamson wrote:
> On Wed, 7 Sep 2016 23:36:28 +0530
> Kirti Wankhede <address@hidden> wrote:
>> On 9/7/2016 10:14 PM, Alex Williamson wrote:
>>> On Wed, 7 Sep 2016 21:45:31 +0530
>>> Kirti Wankhede <address@hidden> wrote:
>>>> On 9/7/2016 2:58 AM, Alex Williamson wrote:  
>>>>> On Wed, 7 Sep 2016 01:05:11 +0530
>>>>> Kirti Wankhede <address@hidden> wrote:
>>>>>> On 9/6/2016 11:10 PM, Alex Williamson wrote:    
>>>>>>> On Sat, 3 Sep 2016 22:04:56 +0530
>>>>>>> Kirti Wankhede <address@hidden> wrote:
>>>>>>>> On 9/3/2016 3:18 AM, Paolo Bonzini wrote:      
>>>>>>>>> On 02/09/2016 20:33, Kirti Wankhede wrote:        


> Philosophically, mdev devices should be entirely independent of one
> another.  A user can set the same iommu context for multiple mdevs
> by placing them in the same container.  A user should be able to
> stop using an mdev in one place and start using it somewhere else.
> It should be a fungible $TYPE device.  It's an NVIDIA-only requirement
> that imposes this association of mdev devices into groups and I don't
> particularly see it as beneficial to the mdev architecture.  So why
> make it a standard part of the interface?

Yes, I agree. This might not be each vendor's requirement.

> We could do keying at the layer you suggest, assuming we can find
> something that doesn't restrict the user, but we could make that
> optional.  

We can key on 'container'. Devices should be in same VFIO 'container'.
open() call should fail if they are found to be in different containers.

> For instance, say we did key on pid, there could be an
> attribute in the supported types hierarchy to indicate this type
> supports(requires) pid-sets.  Each mdev device with this attribute
> would create a pid-group file in sysfs where libvirt could associate
> the device.  Only for those mdev devices requiring it.

We are OK with this suggestion if this works of libvirt integration.
We can have file in types directory in supported types as 'requires_group'.


> The alternative is that we need to find some mechanism for this
> association that doesn't impose arbitrary requirements, and potentially
> usage restrictions on vendors that don't have this need.  Thanks,
> Alex

reply via email to

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