On Tue, Apr 8, 2025 at 10:13 AM David Matlack <dmatlack@xxxxxxxxxx> wrote: > > On Fri, Apr 4, 2025 at 12:39 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > This series is well tested except for one notable gap: I was not able to > > fully test the AMD IOMMU changes. Long story short, getting upstream > > kernels into our full test environments is practically infeasible. And > > exposing a device or VF on systems that are available to developers is a > > bit of a mess. > > > > The device the selftest (see the last patch) uses is an internel test VF > > that's hosted on a smart NIC using non-production (test-only) firmware. > > Unfortunately, only some of our developer systems have the right NIC, and > > for unknown reasons I couldn't get the test firmware to install cleanly on > > Rome systems. I was able to get it functional on Milan (and Intel CPUs), > > but APIC virtualization is disabled on Milan. Thanks to KVM's force_avic > > I could test the KVM flows, but the IOMMU was having none of my attempts > > to force enable APIC virtualization against its will. > > (Sean already knows this but just sharing for the broader visibility.) > > I am working on a VFIO selftests framework and helper library that we > can link into the KVM selftests to make this kind of testing much > easier. It will support a driver framework so we can support testing > against different devices in a common way. Developers/companies can > carry their own out-of-tree drivers for non-standard/custom test > devices, e.g. the "Mercury device" used in this series. > > I will send an RFC in the coming weeks. If/when my proposal is merged, > then I think we'll have a clean way to get the vfio_irq_test merged > upstream as well. This RFC can be found here: https://lore.kernel.org/kvm/20250523233018.1702151-1-dmatlack@xxxxxxxxxx/