On Wed, 20 Sep 2023 15:12:59 -0300 Jason Gunthorpe <j...@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.d...@intel.com> wrote: > > > > > >-----Original Message----- > > > >From: Cédric Le Goater <c...@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 >
