On Fri, Nov 21, 2025 at 10:30:45AM -0500, Laine Stump wrote: > > On 11/6/2025 10:49 AM, Ján Tomko wrote: > > > This does not specify which iommufd object it is, just to use the > > > default one. > > > > > > It's perfect for now, we might need a different element if using > > > anything else than iommufd0 starts making sense. > > Yeah, I think earlier versions of the patches explicitly gave the iommufd > object name used by each device (e.g. literally "iommufd0"), and we deemed > that "too much information", recommending to instead just say "use it" or > "don't use it", and then later we can add an iommufdIndex or something that > would default to 0, and then could contain other values if multiple iommufd > objects were needed (and so, e.g., if two devices had "iommufd='yes' > iommufdIndex='1'" then they would both be setup to use the same > (non-default) iommufd (maybe "iommufd1"). > > So for right now while we're just supporting a single iommufd object per > domain, the current proposed XML should be fine.
Link to the relevant bit from that previous conversation: [1]. I agree that we can just extend the schema with an additional attribute if and when multiple iommufds become something that we actually want. > > > Should we resurrect the old attribute and use: > > > <driver name="iommufd"/> > > > > > > The idea being that later in time, when it will no longer make sense > > > to use "legacy" VFIO, we will retire it again. > > My understanding is that this is still classified as "VFIO device > assignment", but just using an iommufd for communication, so it's not "let's > do this instead of VFIO", but "let's do VFIO *this* way instead of the other > way". Quoting Alex Williamson[2]: [...] while initially IOMMUFD is only used by vfio, the intention is that it becomes the default userspace IOMMU interface for not only vfio, but also vdpa and similar technologies. So I agree with your take that a new attribute is more appropriate. Further down the line, we can add the same attribute to other devices that can take advantage of iommufd. Overall, the current implementation seems fine to me, modulo of course the issues that have already been pointed out. [1] https://lists.libvirt.org/archives/list/[email protected]/message/QRYZSHUTFVFNKIWAXLATXUB4CLSTNSTM/ [2] https://issues.redhat.com/browse/RHEL-36153?focusedId=24825981&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24825981 -- Andrea Bolognani / Red Hat / Virtualization
