On Thu, Feb 06, 2025 at 04:38:55PM -0400, Jason Gunthorpe wrote: > On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote: > > On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote: > > > On Thu, Feb 06, 2025 at 06:18:14PM +0000, Shameerali Kolothum Thodi wrote: > > > > > > > > So even if you invent an iommu ID we cannot accept it as a handle to > > > > > create viommu in iommufd. > > > > > > > > Creating the vIOMMU only happens when the user does a cold/hot plug of > > > > a VFIO device. At that time Qemu checks whether the assigned id matches > > > > with whatever the kernel tell it. > > > > > > This is not hard up until the guest is started. If you boot a guest > > > without a backing viommu iommufd object then there will be some more > > > complexities. > > > > Yea, I imagined that things would be complicated with hotplugs.. > > > > On one hand, I got the part that we need some fixed link forehand > > to ease migration/hotplugs. > > > > On the other hand, all IOMMUFD ioctls need a VFIO device FD, which > > brings the immediate attention that we cannot even decide vSMMU's > > capabilities being reflected in its IDR/IIDR registers, without a > > coldplug device > > As Daniel was saying this all has to be specifiable on the command > line. > > IMHO if the vSMMU is not fully specified by the time the boot happens > (either explicity via command line or implicitly by querying the live > HW) then it qemu should fail.
Though that makes sense, that would assume we could only support the case where a VM has at least one cold plug device per vSMMU? Otherwise, even if we specify vSMMU to which pSMMU via a command line, we can't get access to the pSMMU via IOMMU_GET_HW_INFO.. Thanks Nicolin
