Re: [PATCH v1 15/22] Add iommufd configure option

[Alex Williamson]

On Wed, 20 Sep 2023 15:12:59 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Wed, Sep 20, 2023 at 12:01:42PM -0600, Alex Williamson wrote:
> > On Wed, 20 Sep 2023 03:42:20 +0000
> > "Duan, Zhenzhong" <zhenzhong.duan@intel.com> wrote:
> >   
> > > >-----Original Message-----
> > > >From: Cédric Le Goater <clg@redhat.com>
> > > >Sent: Wednesday, September 20, 2023 1:08 AM
> > > >Subject: Re: [PATCH v1 15/22] Add iommufd configure option
> > > >
> > > >On 8/30/23 12:37, Zhenzhong Duan wrote:    
> > > >> This adds "--enable-iommufd/--disable-iommufd" to enable or disable
> > > >> iommufd support, enabled by default.    
> > > >
> > > >Why would someone want to disable support at compile time ? It might    
> > > 
> > > For those users who only want to support legacy container feature?
> > > Let me know if you still prefer to drop this patch, I'm fine with that.
> > >   
> > > >have been useful for dev but now QEMU should self-adjust at runtime
> > > >depending only on the host capabilities AFAIUI. Am I missing something ? 
> > > >   
> > > 
> > > IOMMUFD doesn't support all features of legacy container, so QEMU
> > > doesn't self-adjust at runtime by checking if host supports IOMMUFD.
> > > We need to specify it explicitly to use IOMMUFD as below:
> > > 
> > >     -object iommufd,id=iommufd0
> > >     -device vfio-pci,host=0000:02:00.0,iommufd=iommufd0  
> > 
> > There's an important point here that maybe we've let slip for too long.
> > Laine had asked in an internal forum whether the switch to IOMMUFD was
> > visible to the guest.  I replied that it wasn't, but this note about
> > IOMMUFD vs container features jogged my memory that I think we still
> > lack p2p support with IOMMUFD, ie. IOMMU mapping of device MMIO.  It
> > seemed like there was something else too, but I don't recall without
> > some research.  
> 
> I think p2p is the only guest visible one.
> 
> I still expect to solve it :\
> 
> > Ideally we'd have feature parity and libvirt could simply use the
> > native IOMMUFD interface whenever both the kernel and QEMU support it.
> > 
> > Without that parity, when does libvirt decide to use IOMMUFD?
> > 
> > How would libvirt know if some future IOMMUFD does have parity?  
> 
> At this point I think it is reasonable that iommufd is explicitly
> opted into.
> 
> The next step would be automatic for single PCI device VMs (p2p is not
> relavent)

And when a second PCI device is hot-plugged into the VM and it behaves
differently from a VM with multiple statically attached devices?  Seems
like it's an opt-in until full p2p support, then an opt-out for
potential bugs.  Thanks,

Alex

> The final step would be automatic if kernel supports P2P. I expect
> libvirt will be able to detect this from an open'd /dev/iommu.
> 
> Jason
>