On Tue, May 27, 2025 at 06:51:50PM -0700, Nathan Chen wrote:
> 
> 
> On 5/20/2025 6:01 AM, Daniel P. Berrangé wrote:
> > > Add support for an "iommufd" virDomainIOMMUDef member that will be
> > > translated to a qemu "-object iommufd" command line argument. This
> > > iommufd struct has an "id" member to specify the iommufd object id
> > > that can be associated with a passthrough device, and an "fd"
> > > member to specify the fd for externally opening the /dev/iommu and
> > > VFIO cdev by a management layer.
> > > 
> > > @@ -28310,6 +28406,16 @@ virDomainIOMMUDefFormat(virBuffer *buf,
> > >       virXMLFormatElement(&childBuf, "driver", &driverAttrBuf, NULL);
> > > +    if (iommu->iommufd) {
> > > +        virBufferAddLit(&childBuf, "<iommufd>\n");
> > > +        virBufferAdjustIndent(&childBuf, 2);
> > > +        virBufferAsprintf(&childBuf, "<id>%s</id>\n", 
> > > iommu->iommufd->id);
> > > +        if (iommu->iommufd->fd)
> > > +            virBufferAsprintf(&childBuf, "<fd>%s</fd>\n", 
> > > iommu->iommufd->fd);
> > I'm not convinced we should be exposing the QEMU "id" in the XML.
> > It is an identifier libvirt uses internally for configuring
> > QEMU, but I don't see a reason why the end user needs to control
> > its name. I'm similarly not sure we should expose an FD to
> > users eitherm, just use that internally when talking to QEMU.
> > 
> > IOW, why aren't we just having "iommu='yes'"  as an attribute
> > on the <iommu> device, avoiding all the logic below that
> > tries to force all devices to use the same configuration.
> 
> That makes sense - I will simply have an attribute like "iommufd='yes'" as
> an attribute in the next revision instead of having users specify the
> iommufd id themselves.
> 
> As for exposing an FD to users, this is meant to mirror the qemu
> implementation where users can specify the FD string [0], so I think we
> should keep this part as-is.

The FD passing functionality exposed by QEMU is targetted at mgmt
apps like libvirt, which apply sandboxing to QEMU, and thus need
to pass in pre-opened FDs. Most of the time, this is not something
that libvirt will expose to its own API/XML users, as FDs are a
very low level concept that is backend implementation specific.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Reply via email to