On 9/8/2016 3:43 AM, Alex Williamson wrote: > On Wed, 7 Sep 2016 23:36:28 +0530 > Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: > >> On 9/7/2016 10:14 PM, Alex Williamson wrote: >>> On Wed, 7 Sep 2016 21:45:31 +0530 >>> Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: >>> >>>> On 9/7/2016 2:58 AM, Alex Williamson wrote: >>>>> On Wed, 7 Sep 2016 01:05:11 +0530 >>>>> Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: >>>>> >>>>>> On 9/6/2016 11:10 PM, Alex Williamson wrote: >>>>>>> On Sat, 3 Sep 2016 22:04:56 +0530 >>>>>>> Kirti Wankhede <kwankhede@xxxxxxxxxx> 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'. Thanks, Kirti > 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 > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
