From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DB9730D3E1 for ; Thu, 4 Jun 2026 23:14:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780614876; cv=none; b=U1Uj8/aSqmFthnr8tbibaFed40MByHUwJmxkFeKuf27s+wemw5lqAGzHsn4ShhvnKfvLIKdHOox34PLJ4ZquS6PmMgN5fdtqfjx24apD0jpU3DoIrhRtVBYCsxpjkmm3o1KUMNxrYlMShrnTiTyuSxGbD8pQLXVQqdOyeeyTLnI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780614876; c=relaxed/simple; bh=KbIBD6Typey6Tj7uJR/pDL/KpVHmXj3HB1WG71/DbgA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tNoUI5WJlumX7q4sauN1PuL1+T691noWwsQv/4gC8kFI52kvFjeYLsGG1fiKX0TtOBQ74Rfx/lXilhq2hjxkdbacgbuF3VvmcTodHYD1Njepc1erKgkCgopsqryOCKdiglGwRUMJw1ZGkpBEs8lAXOW1BmzulhA/CiYLvL7Ch5U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=uP/Osk2f; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uP/Osk2f" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-36d98b828c8so507021a91.2 for ; Thu, 04 Jun 2026 16:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780614874; x=1781219674; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=mS9MJ5kCrWOlM6ucjjTqvWj1HBAg+22TNTpHduIiXcE=; b=uP/Osk2fEuGVQvcQoZRPIVfLIy9uORK3Ra4um+6wpTSWHZjXaRLgVhtyRmX7ja+Tug 6lxR1+9j9JpohGLmm7jyXdpexNf3/gYyXMuEiJE/mrTcNY2OFeaXbJgkRGxWh7RXn8ek YRI/8Q3FG7TfdYRFUG6b9fcXGz2cvYD7ViYIoX/lfT4IqWKLYz6tYGmNnbOSWPL88/d5 LgPudn99ggM4Lzdgc5NcUeaxEVJBf9Ggur+mwj45SGbWqmeCETTYysgdicTvdVdOt7k/ G2xkDhjOk8RmoP+36LG5Os2GPhabpA18i/3oYKrQHHAdDzy7HzSdv9rGKbgIypQZZJCM /PXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780614874; x=1781219674; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mS9MJ5kCrWOlM6ucjjTqvWj1HBAg+22TNTpHduIiXcE=; b=QD5AnjZRi0YVROfXznMHPhoRdAeX4sd0ZRe5yVE4g20Po2dAT1GtAnqXAukTO8G9Jj vOQS/OupGODde6Qx7muhL8ACeQORh9i+AOQhpPylONQUBpO37qmfF/WjmEKuk0zttzWE rSYu9pr2NBYoptOq3po3CBNrCS/iFaLHY9DjY+aCptsSu6jYBsqSheW3pkUNHJFUKKmB mJijz6WsvSlSDLrJOrbW9IzrDrvPgVmCpAVnA2Tq6ICnshcAI9TqYkwhV6PRP48wZZ1y VQfZ6YMHpQQAWIw4kyb4zjfCBipvO0SqKllQIL4XjFRA9OslVuxEehExnZ6zLLRHBKIE ZrkA== X-Forwarded-Encrypted: i=1; AFNElJ9PHHGM7r7fKGatSCvPKxifcgLQ+Vx5gTCD2xp/r4O/V75/EOZ0iU3JLZnH7m9K3MN33lknv7O+7gGVI0E=@vger.kernel.org X-Gm-Message-State: AOJu0Yya59fgS2GoZOys8Oc8RoXtMikH8BWKjlBAdTh4t7w5p8nchu5M 8h0p0/h8nFAbraCfITa9KSttzedqVg1mAwgumYwAJst6TR+AnpeSFLawelt2GgA9/w3IDlV21pN NHpBRNQ== X-Received: from pjbbo10.prod.google.com ([2002:a17:90b:90a:b0:36b:d248:5f89]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:394e:b0:36a:aeaf:ab2a with SMTP id 98e67ed59e1d1-370f0d4c33emr986368a91.19.1780614873561; Thu, 04 Jun 2026 16:14:33 -0700 (PDT) Date: Thu, 4 Jun 2026 16:14:32 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260604020143.748245-1-jrhilke@google.com> <20260604020143.748245-8-jrhilke@google.com> Message-ID: Subject: Re: [PATCH v5 07/21] KVM: selftests: Verify IRQ bypass works in IRQ test From: Sean Christopherson To: Josh Hilke Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Alex Williamson Content-Type: text/plain; charset="us-ascii" On Thu, Jun 04, 2026, Sean Christopherson wrote: > On Thu, Jun 04, 2026, Sean Christopherson wrote: > > The shortlog is at best misleading. There are zero guarantees that IRQ bypass > > is supported and enabled. > > > > On Thu, Jun 04, 2026, Josh Hilke wrote: > > > From: David Matlack > > > > > > Trigger interrupts from a VFIO device instead of emulating interrupts > > > > It's not emulating, it's synthesizing. Emulating implies there's a device of > > some kind that the test is mimicking. > > > > > using KVM eventfds. This verifies that guests receive interrupts via IRQ > > > bypass. > > > > No, it verifies that delivery of a VFIO MSI-X through VFIO=>KVM works, and *may* > > verify IRQ bypass. And all of that very much relies on the eventfds to be in > > place. > > > > > @@ -119,7 +160,17 @@ int main(int argc, char **argv) > > > vm = vm_create_with_vcpus(nr_vcpus, guest_code, vcpus); > > > vm_install_exception_handler(vm, vector, guest_irq_handler); > > > > > > - eventfd = kvm_new_eventfd(); > > > + if (device_bdf) { > > > + iommu = iommu_init(default_iommu_mode); > > > > This needs: > > > > diff --git tools/testing/selftests/kvm/irq_test.c tools/testing/selftests/kvm/irq_test.c > > index cf4568718cee..2e7e100d4815 100644 > > --- tools/testing/selftests/kvm/irq_test.c > > +++ tools/testing/selftests/kvm/irq_test.c > > @@ -235,6 +235,8 @@ int main(int argc, char **argv) > > } > > > > if (device_bdf) { > > + __open_path_or_exit("/dev/iommu", O_RDONLY, "Is IOMMUFD available?"); > > + > > iommu = iommu_init(default_iommu_mode); > > *sigh* > > > This is beyond frustating. I have A PERFECTLY FUNCTIONAL KERNEL, but this test > VERY SUBTLY "defaults" to IOMMUFD. ARGH!!!!! Ok, here's what I ended up with. A param to let the user force a specific type: printf("-t Override the IOMMU type to use (vfio_type1_iommu or iommufd)\n"); And then auto-probe logic to make a halfway decent guess as to which type/mode to use. static const char *probe_iommu_type(void) { int io_fd; io_fd = open("/dev/iommu", O_RDONLY); if (io_fd >= 0) { close(io_fd); return MODE_IOMMUFD; } io_fd = __open_path_or_exit("/dev/vfio", O_RDONLY, "Is VFIO (or IOMMUFD) loaded and enabled?"); close(io_fd); return MODE_VFIO_TYPE1_IOMMU; } ... if (!iommu_type) iommu_type = probe_iommu_type(); I'll probably throw a TODO in there, because the VFIO/IOMMU infrastructure really needs to handle this, *especially* since "default_iommu_mode" is globally visible. Hardcoding a "default" to an entirely optional thing is just evil. E.g. instead of iommu_init() => lookup_iommu_mode() using default_iommu_mode when passed a NULL pointer, have it choose the type that's most likely to work. Then the IRQ test can drop its probing logic.