On Fri, 9 Sep 2016 00:18:10 +0530 Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: > 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. If we're operating with a vIOMMU then each vfio-group needs to be in its own address space and will therefore be in separate containers. Even without that, it would be entirely valid for a user to put groups in separate containers, QEMU just chooses to use the same container for efficiency and to avoid accounting issues with multiple containers. There's also no interface for the vfio bus driver to get at the container currently. > > 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'. Ok, I wish there was a better way, we'll see what libvirt folks think. If we can't make it transparent for mdev vendors that don't require it, at least we can define an API extension within mdev that libvirt can use to discover the requirement and support it. Thanks, Alex -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list