On Thu, Jan 30, 2025 at 09:51:55AM -0800, Nathan Chen wrote: > > > > Hi Daniel, > > > > > > > Top level libvirt device representation in XML is based on the device > > > > *class*, not the specific device impl. Adding a <nestedSmmuv3> device > > > > type XML element in libvirt is totally inappropriate. Any configuration > > > > must be done beneath the <iommu> element. > > > Would keeping track of PXB <=> host SMMU nodes be better represented with a > > > <nestedSmmuv3> PXB attribute like below, when the "nestedSmmuv3" IOMMU model > > > is specified? This method would be simplest IMO because we could omit > > > keeping track of the nestedSmmuv3 bus number in the virDomainDef struct > > > since its association with a PXB controller would already be baked-in. > > > > > > <devices> > > > ... > > > <controller type='pci' index='1' model='pcie-expander-bus'> > > > <model name='pxb-pcie'/> > > > <target busNr='254'/> > > > <nestedSmmuv3>smmu3.0x0000000012000000</nestedSmmuv3> > > > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> > > > </controller> > > > ... > > > <iommu model='nestedSmmuv3'/> > > > </devices> > > > > The '<nestedSmmuv3>smmu3.0x0000000012000000</nestedSmmuv3>' bit > > is also wierd, because it never appears in the QEMU command line > > at all. Some kind of implicit association seems to be taking > > place behind the scenes and that is unlikely to be a desirable > > thing. We need to model associations between devices explicitly > > and directly pass this on to QEMU. > > > > If the nestedSmmuv3 is assocaited with a host SMMUv3 device, > > then that association should be represented on the <iommu> > > device, and this mapping passed to QEMU. > > The '<nestedSmmuv3>smmu3.0x0000000012000000</nestedSmmuv3>' bit will be > moved to the <iommu> definition in the next revision. > > I agree that explicitly specifying the host SMMU node name in QEMU would > make the host to guest SMMU association more clear. But the current QEMU > implementation appears more flexible in allowing us to create nestedSmmuv3 > instances and then imply the association to a host SMMU node based on the > PCIe topology isolating devices under different PXBs. I think we should > discuss this further on the QEMU thread with Shameer before he sends out the > second revision of his series, then adjust the libvirt implementation based > on the next QEMU revision. "auto-magic" associations between different pieces has too large a scope to bite us at a later date. libvirt's goal has always been to make everything that's functionally impacting a guest device be 100% explicit. So I don't think we should be implying mappings to the host SMMU in QEMU at all, QEMU must be told what to map to. 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 :|
