Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update vIOMMU

[Yi Liu]

On 2024/11/16 08:34, Jason Gunthorpe wrote:
> On Fri, Nov 15, 2024 at 02:07:41PM -0800, Nicolin Chen wrote:
> > On Thu, Nov 14, 2024 at 12:20:10PM -0400, Jason Gunthorpe wrote:
> > > On Wed, Nov 13, 2024 at 07:18:42PM -0800, Nicolin Chen wrote:
> > > > > so the user would try to create vDevices with a given viommu_obj until
> > > > > failure, then it would allocate another viommu_obj for the failed device.
> > > > > is it? sounds reasonable.
> > > >
> > > > Yes. It is the same as previously dealing with a nesting parent:
> > > > test and allocate if fails. The virtual IOMMU driver in VMM can
> > > > keep a list of the vIOMMU objects for each device to test.
> > >
> > > The viommu object should be tied to the VMM's vIOMMU vHW object that
> > > it is paravirtualizing toward the VM.
> > >
> > > So we shouldn't be creating viommu objects on demand, it should be
> > > created when the vIOMMU is created, and the presumably the qemu
> > > command line will describe how to link vPCI/VFIO functions to vIOMMU
> > > instances. If they kernel won't allow the user's configuration then it
> > > should fail, IMHO.
> >
> > Intel's virtual IOMMU in QEMU has one instance but could create
> > two vIOMMU objects for devices behind two different pIOMMUs. So,
> > in this case, it does the on-demand (or try-and-fail) approach?
>
> I suspect Intel does need viommu at all, and if it ever does it will
> not be able to have one instance..

hmmm. As long as I got, the viommu_obj is a representative of the hw
IOMMU slice of resource used by the VM. It is hence instanced per hw
iommu. Based on this, one vIOMMU can have multiple or one viommu_obj.
Either should be allowed by design.

BTW. @Nic, I think the viommu_obj instance is not strictly be per hw
IOMMUs. e.g. two devices behind one hw IOMMU can have their own viommu_obj
as well. Is it? I didn't see a problem for it. So the viommu_obj is
instanced >= hw IOMMU number used by the VM.

Regards,
Yi Liu