[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RFC 00/18] vfio: Adopt iommufd
From: |
Tian, Kevin |
Subject: |
RE: [RFC 00/18] vfio: Adopt iommufd |
Date: |
Thu, 28 Apr 2022 03:21:45 +0000 |
> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Wednesday, April 27, 2022 12:22 AM
> > >
> > > My expectation would be that libvirt uses:
> > >
> > > -object iommufd,id=iommufd0,fd=NNN
> > > -device vfio-pci,fd=MMM,iommufd=iommufd0
> > >
> > > Whereas simple QEMU command line would be:
> > >
> > > -object iommufd,id=iommufd0
> > > -device vfio-pci,iommufd=iommufd0,host=0000:02:00.0
> > >
> > > The iommufd object would open /dev/iommufd itself. Creating an
> > > implicit iommufd object is someone problematic because one of the
> > > things I forgot to highlight in my previous description is that the
> > > iommufd object is meant to be shared across not only various vfio
> > > devices (platform, ccw, ap, nvme, etc), but also across subsystems, ex.
> > > vdpa.
> >
> > Out of curiosity - in concept one iommufd is sufficient to support all
> > ioas requirements across subsystems while having multiple iommufd's
> > instead lose the benefit of centralized accounting. The latter will also
> > cause some trouble when we start virtualizing ENQCMD which requires
> > VM-wide PASID virtualization thus further needs to share that
> > information across iommufd's. Not unsolvable but really no gain by
> > adding such complexity. So I'm curious whether Qemu provide
> > a way to restrict that certain object type can only have one instance
> > to discourage such multi-iommufd attempt?
>
> I don't see any reason for QEMU to restrict iommufd objects. The QEMU
> philosophy seems to be to let users create whatever configuration they
> want. For libvirt though, the assumption would be that a single
> iommufd object can be used across subsystems, so libvirt would never
> automatically create multiple objects.
I like the flexibility what the objection approach gives in your proposal.
But with the said complexity in mind (with no foreseen benefit), I wonder
whether an alternative approach which treats iommufd as a global
property instead of an object is acceptable in Qemu, i.e.:
-iommufd on/off
-device vfio-pci,iommufd,[fd=MMM/host=0000:02:00.0]
All devices with iommufd specified then implicitly share a single iommufd
object within Qemu.
This still allows vfio devices to be specified via fd but just requires Libvirt
to grant file permission on /dev/iommu. Is it a worthwhile tradeoff to be
considered or just not a typical way in Qemu philosophy e.g. any object
associated with a device must be explicitly specified?
Thanks
Kevin
- Re: [RFC 00/18] vfio: Adopt iommufd, (continued)
- Re: [RFC 00/18] vfio: Adopt iommufd, Alex Williamson, 2022/04/22
- Re: [RFC 00/18] vfio: Adopt iommufd, Daniel P . Berrangé, 2022/04/25
- Re: [RFC 00/18] vfio: Adopt iommufd, Jason Gunthorpe, 2022/04/25
- Re: [RFC 00/18] vfio: Adopt iommufd, Alex Williamson, 2022/04/25
- RE: [RFC 00/18] vfio: Adopt iommufd, Tian, Kevin, 2022/04/26
- Re: [RFC 00/18] vfio: Adopt iommufd, Jason Gunthorpe, 2022/04/26
- Re: [RFC 00/18] vfio: Adopt iommufd, Alex Williamson, 2022/04/26
- Re: [RFC 00/18] vfio: Adopt iommufd, Jason Gunthorpe, 2022/04/26
- Re: [RFC 00/18] vfio: Adopt iommufd, Alex Williamson, 2022/04/26
- Re: [RFC 00/18] vfio: Adopt iommufd, Jason Gunthorpe, 2022/04/26
- RE: [RFC 00/18] vfio: Adopt iommufd,
Tian, Kevin <=
- Re: [RFC 00/18] vfio: Adopt iommufd, Alex Williamson, 2022/04/28
- Re: [RFC 00/18] vfio: Adopt iommufd, Daniel P . Berrangé, 2022/04/28
- RE: [RFC 00/18] vfio: Adopt iommufd, Tian, Kevin, 2022/04/28
Re: [RFC 00/18] vfio: Adopt iommufd, Eric Auger, 2022/04/25
RE: [RFC 00/18] vfio: Adopt iommufd, Shameerali Kolothum Thodi, 2022/04/26