All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Hilke <jrhilke@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, Alex Williamson <alex@shazbot.org>
Subject: Re: [PATCH v2 00/14] KVM: selftests: Link with VFIO selftests lib and test device interrupts
Date: Thu, 2 Apr 2026 00:38:29 +0000	[thread overview]
Message-ID: <ac26haU_7nXYWke1@google.com> (raw)
In-Reply-To: <CALzav=cO48f7f8yaN6EsSL4uGpojvY7gmCe9oOy+sP_+Kii4mw@mail.gmail.com>

On Wed, Apr 01, 2026 at 04:58:34PM -0700, David Matlack wrote:
> On Wed, Apr 1, 2026 at 4:42 PM Josh Hilke <jrhilke@google.com> wrote:
> >
> > On Wed, Apr 1, 2026 at 1:12 PM David Matlack <dmatlack@google.com> wrote:
> > >
> > > On 2026-04-01 12:07 PM, Sean Christopherson wrote:
> > > > On Wed, Apr 01, 2026, David Matlack wrote:
> > > > > On 2026-04-01 11:17 AM, Sean Christopherson wrote:
> > > > > > On Tue, Mar 31, 2026, Josh Hilke wrote:
> > >
> > > > > Agree this would be nice to have. Is this a blocker for this series?
> > > >
> > > > Yes.  KVM selftests need to assert there's a driver before trying to proceed.
> > >
> > > That exists in the new test:
> > >
> > > static int setup_msi(struct vfio_pci_device *device, bool use_device_msi)
> > > {
> > >         const int flags = MAP_SHARED | MAP_ANONYMOUS;
> > >         const int prot = PROT_READ | PROT_WRITE;
> > >         struct dma_region *region;
> > >
> > >         if (use_device_msi) {
> > >                 /* A driver is required to generate an MSI. */
> > >                 TEST_REQUIRE(device->driver.ops);
> > >
> > > But I think you are also asking to have a helper that prints out the
> > > list of available drivers in this case. That should be trivial to add.
> > >
> > > VFIO selftests could expose add a helper that handles checking for
> > > device->driver.ops and, if null, printing an error message and list of
> > > available drivers and exiting with KSFT_SKIP.
> > >
> > > One wrinkle here is we are probably going to merge a driver soon that
> > > does not support send_msi():
> > >
> > >   https://lore.kernel.org/kvm/20260331172241.50456-1-rubind@nvidia.com/
> > >
> > > So we should also have an API for that. e.g. Add 2 helpsers:
> > >
> > >   - vfio_pci_has_driver()
> > >   - vfio_pci_has_driver_send_msi()
> > >
> > > This test would use the latter.
> >
> > Ack. I'll add a patch in the series to add these functions to the vfio
> > library in v3.
> >
> > >
> > > > > > struct vfio_pci_device *kvm_vfio_device_init(const char *bdf)
> > > > > > {
> > > > > >   struct vfio_pci_device *device;
> > > > > >   struct iommu *iommu;
> > > > > >
> > > > > >   iommu = iommu_init(default_iommu_mode);
> > > > > >
> > > > > >   device = vfio_pci_device_init(bdf, iommu);
> > > > > >   if (!device) {
> > > > > >           vfio_pci_device_print_drivers(stderr);
> > > > > >           TEST_FAIL("No driver found for BDF '%s'", bdf);
> > > > > >   }
> > > > > >   return device;
> > > > > > }
> > > > > >
> > > > > > Because as is, this requires way too much a priori knowledge and magic for
> > > > > > upstream.  The user shouldn't have to dig through code just to understand what
> > > > > > devices are supported.
> > > > > >
> > > > > > Ideally, VFIO selftests would also provide a script, utility, and/or helper to
> > > > > > identify BDFs for devices it has drivers for.  In my experience, binding a device
> > > > > > to VFIO is trivial.  Finding the device in the first place is more annoying.
> > > > >
> > > > > Agree this would be nice to have. Is this a blocker for this series?
> > > >
> > > > Yes.  As I mentioned to Josh off-list, I'm not willing to accept a "we pinky-swear
> > > > we'll make this stuff user friendly".  It's not that I don't trust you and Josh
> > > > (and others), it's that for me, this level of user-friendly behavior isn't nice
> > > > to have, it's mandatory for these tests to be usable upstream.
> > > >
> > > > Internally we can squeak by with barebones, unhelpful tests, because the run
> > > > commands are often hardcoded somewhere and there is piles of documentation elsewhere.
> > > > But for upstream, none of that holds true.
> > > >
> > > > If it were weeks of effort, I would be more open to treating this as nice to have,
> > > > but AFAICT writing the code should be less than a days worth of work.
> > >
> > > Yeah that's fine, I don't think it adds too much extra work, and it's
> > > something I'd like to have anyway. I just wanted to confirm if it should
> > > be part (or merged ahead of this series) or can be separate. Thanks!
> >
> > So I need to add kvm_vfio_device_init() and it will call
> > vfio_pci_has_driver(). Then, kvm_vfio_device_init() will TEST_FAIL if
> > vfio_pci_has_driver() returns false, correct?
> >
> > Should kvm_vfio_device_init() live in
> > tools/testing/selftests/kvm/lib/kvm_util.c?
> 
> I was thinking the new test would do:
> 
>   TEST_REQUIRE(vfio_pci_has_driver_send_msi(device));
> 
> instead of:
> 
>   TEST_REQUIRE(device->driver.ops);
> 
> vfio_pci_has_driver_send_msi() would call vfio_pci_has_driver()
> internally and also check that send_msi op is non-null. Both functions
> would also log error messages if driver/send_msi is missing to help
> the user, as Sean requested.
> 
> And you'll also need to a patch to add a helper script to print the
> list of BDFs on the current host that have a VFIO selftests driver. It
> might make sense to send that as a standalone patch if Sean is ok with
> that.

That makes sense for setup_msi(). But in Sean's implementation of
kvm_vfio_device_init() above, it looks like he wants the test to fail if
there's no VFIO selftest driver for the BDF passed into the test.

  reply	other threads:[~2026-04-02  0:38 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 19:40 [PATCH v2 00/14] KVM: selftests: Link with VFIO selftests lib and test device interrupts Josh Hilke
2026-03-31 19:40 ` [PATCH v2 01/14] KVM: selftests: Build and link sefltests/vfio/lib into KVM selftests Josh Hilke
2026-04-01 18:17   ` Sean Christopherson
2026-04-01 23:49     ` Josh Hilke
2026-03-31 19:40 ` [PATCH v2 02/14] KVM: selftests: Add helper functions for IRQ testing Josh Hilke
2026-04-01 18:26   ` Sean Christopherson
2026-04-01 23:54     ` Josh Hilke
2026-03-31 19:40 ` [PATCH v2 03/14] KVM: selftests: Add vfio_pci_irq_test Josh Hilke
2026-04-01 19:58   ` Sean Christopherson
2026-04-02  0:13     ` Josh Hilke
2026-04-02 17:52       ` Sean Christopherson
2026-03-31 19:40 ` [PATCH v2 04/14] KVM: selftests: Reproduce tests that rely on randomization Josh Hilke
2026-03-31 19:40 ` [PATCH v2 05/14] KVM: selftests: Add support for random host IRQ affinity Josh Hilke
2026-04-01 20:01   ` Sean Christopherson
2026-04-02  1:16     ` Josh Hilke
2026-03-31 19:40 ` [PATCH v2 06/14] KVM: selftests: Allow blocking vCPUs via HLT Josh Hilke
2026-04-01 20:03   ` Sean Christopherson
2026-03-31 19:40 ` [PATCH v2 07/14] KVM: selftests: Add support for physical device MSI triggers Josh Hilke
2026-04-01 20:24   ` Sean Christopherson
2026-04-02  3:23     ` Josh Hilke
2026-03-31 19:40 ` [PATCH v2 08/14] KVM: selftests: Add option to clear GSI routes Josh Hilke
2026-03-31 19:40 ` [PATCH v2 09/14] KVM: selftests: Make test IRQ count configurable Josh Hilke
2026-03-31 19:40 ` [PATCH v2 10/14] KVM: selftests: Add support for NMI delivery Josh Hilke
2026-04-01 20:29   ` Sean Christopherson
2026-04-02  5:27     ` Josh Hilke
2026-03-31 19:40 ` [PATCH v2 11/14] KVM: selftests: Add support for vCPU pinning Josh Hilke
2026-04-01 20:55   ` Sean Christopherson
2026-03-31 19:40 ` [PATCH v2 12/14] KVM: selftests: Support testing with multiple vCPUs Josh Hilke
2026-03-31 19:40 ` [PATCH v2 13/14] KVM: selftests: Add xAPIC mode support Josh Hilke
2026-03-31 19:40 ` [PATCH v2 14/14] KVM: selftests: Make vfio_pci_irq_test timeout configurable Josh Hilke
2026-04-01 21:00   ` Sean Christopherson
2026-04-01 18:17 ` [PATCH v2 00/14] KVM: selftests: Link with VFIO selftests lib and test device interrupts Sean Christopherson
2026-04-01 18:52   ` David Matlack
2026-04-01 19:07     ` Sean Christopherson
2026-04-01 20:12       ` David Matlack
2026-04-01 23:41         ` Josh Hilke
2026-04-01 23:58           ` David Matlack
2026-04-02  0:38             ` Josh Hilke [this message]
2026-04-02  1:49               ` Josh Hilke
2026-04-02 17:35                 ` Sean Christopherson
2026-04-02 17:56                   ` David Matlack
2026-04-02 18:07                     ` Josh Hilke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac26haU_7nXYWke1@google.com \
    --to=jrhilke@google.com \
    --cc=alex@shazbot.org \
    --cc=dmatlack@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.