From: "José Expósito" <jose.exposito89@gmail.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Mark Yacoub <markyacoub@google.com>,
igt-dev@lists.freedesktop.org, juhapekka.heikkila@gmail.com
Subject: Re: [PATCH i-g-t] lib/drmtest: Remove VKMS from Exclusion list
Date: Thu, 16 Oct 2025 13:00:10 +0200 [thread overview]
Message-ID: <aPDQOgFtR0aMo4_C@fedora> (raw)
In-Reply-To: <d67971d5-8bc5-4a4d-becf-59696631f21d@bootlin.com>
Hi everyone,
Thanks for CCing me Louis.
On Thu, Oct 16, 2025 at 10:40:32AM +0200, Louis Chauvet wrote:
>
>
> Le 15/10/2025 à 20:16, Kamil Konieczny a écrit :
> > Hi Mark,
> > On 2025-10-09 at 12:53:24 -0400, Mark Yacoub wrote:
> > > Hi Kamil,
> > >
> > > Thanks for your feedback. I'd like to elaborate on my use case to provide
> > > more context about the problem I'm trying to solve.
> > >
> > > I am building IGT for Android, and the same build system is deployed on
> > > both physical hardware and virtual machines. On the hardware, the
> > > appropriate hardware driver is correctly detected, so there are no issues
> > > there. However, on the VM, VKMS is running, but it's currently excluded
> > > from `DRIVER_ANY`, which prevents the tests from running against it. I need
> > > the tests to execute on VKMS in this scenario.
> > >
> > > Using `IGT_FORCE_DRIVER` would require me to fork the build processes for
> > > hardware and VM, which I would prefer to avoid. My goal is to maintain a
> >
> > You do not need to fork it nor recompile, this is env var for
> > CI run with tests, it uses the same igt binaries only makes them
> > using a forced driver when opening card. Now it do not work as
> > no user before needed to force it into vgem or VKMS.
> >
> > In theory you could define it like: export IGT_FORCE_DRIVER=vkms
> > and then all kms tests and core_ ones should honor it.
>
> +CC: José
>
> Hi,
>
> I had the same issue this week, but IGT_FORCE_DRIVER is not enough: all the
> tests using DRIVER_ANY are skipped.
>
> # export IGT_DEVICE=drm:/dev/dri/card0
> # export IGT_FORCE_DRIVER=vkms
> # export IGT_LOG_LEVEL=debug
> # /usr/libexec/igt-gpu-tools/kms_plane
> (kms_plane:125) igt_core-DEBUG: Notice: using IGT_DEVICE env:
> (kms_plane:125) igt_core-DEBUG: [drm:/dev/dri/card0]
> [IGT] kms_plane: executing
> IGT-Version: 2.2-g6d82d231ced6 (x86_64) (Linux:
> 6.17.0-rc6-01217-g1ddd2876eeb9 x86_64)
> Using IGT_SRANDOM=1760602572 for randomisation
> (kms_plane:125) drmtest-DEBUG: Looking for devices to open using filter 0:
> drm:/dev/dri/card0
> (kms_plane:125) drmtest-DEBUG: Filter matched /dev/dri/card0 |
> (kms_plane:125) igt_kmod-DEBUG: Module vkms already inserted
> Test requirement not met in function drm_open_driver, file
> ../igt/lib/drmtest.c:735:
> Test requirement: !(fd<0)
> No known gpu found for chipset flags 0x4294965755 (any)
> Last errno: 2, No such file or directory
> Subtest pixel-format: SKIP (0.000s)
> Subtest pixel-format-source-clamping: SKIP (0.000s)
> Subtest plane-position-covered: SKIP (0.000s)
> Subtest plane-position-hole: SKIP (0.000s)
> Subtest plane-position-hole-dpms: SKIP (0.000s)
> Subtest plane-panning-top-left: SKIP (0.000s)
> Subtest plane-panning-bottom-right: SKIP (0.000s)
> Subtest plane-panning-bottom-right-suspend: SKIP (0.000s)
> Subtest planar-pixel-format-settings: SKIP (0.000s)
> [IGT] kms_plane: exiting, ret=77
> (kms_plane:125) igt_core-DEBUG: Exiting with status code 77
>
> José suggested this fix, it seems to properly use vkms if IGT_FORCE_DRIVER
> is set:
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index a1fb0b5ba..f630bc157 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -350,7 +350,7 @@ int __drm_open_device(const char *name, unsigned int
> chipset)
>
> modulename_to_chipset(dev_name, &chip);
>
> - if ((chipset & chip) == chip) {
> + if ((chipset & chip) == chip || (forced && strcmp(forced, dev_name)
> == 0)) {
> log_opened_device_path(name);
> return fd;
> }
>
> @Mark, is it enough for you?
> @José, do you want to send the proper patch?
Sorry I couldn't send a patch earlier, I have been pretty busy this week.
The reason why VKMS is excluded from DRIVERS_ANY is that, when a test
selects any driver ("drm_open_driver(DRIVER_ANY)") hardware drivers are
prioritized over virtual drivers (vgem, vkms or virtio) to avoid them
being accidentally selected due to device-load ordering.
There is a nice comment in drmtest.h explaining it with more detail. So, in
my opinion, VKMS is correctly excluded from DRIVERS_ANY.
However, I'd expect that setting the IGT_FORCE_DRIVER environment variable to
"vkms" would actually use VKMS for testing.
I have refined a bit the initial workaround I discuss with Louis 2 days ago
and I think this could be an acceptable solution:
diff --git a/lib/drmtest.c b/lib/drmtest.c
index a1fb0b5ba..8f295d436 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -350,6 +350,14 @@ int __drm_open_device(const char *name, unsigned int chipset)
modulename_to_chipset(dev_name, &chip);
+ /*
+ * Virtual drivers like vgem or vkms are excluded from DRIVER_ANY and
+ * therefore it is not possible to use them in tests using the
+ * IGT_FORCE_DRIVER environment variable. Include them when forced.
+ */
+ if (forced && chipset == DRIVER_ANY)
+ chipset |= chip;
+
if ((chipset & chip) == chip) {
log_opened_device_path(name);
return fd;
I don't know if making that check even more precise would be a better solution.
For example, calling a "is_virtual_driver()" helper:
if (forced && chipset == DRIVER_ANY && is_virtual_driver(chip))
chipset |= chip;
I can send a patch with that fix, but I'd appreciate as much feedback as possible
as this code is used by every tests and I don't have enough experience with IGT
to make sure it doesn't introduce a bug.
Best wishes,
Jose
>
> Hav a nice day,
> Louis Chauvet
>
> > Regards,
> > Kamil
> >
> > > unified build system and allow IGT to run on whatever driver is present. Is
> > > there a way to achieve this?
> > >
> > > I understand that the current code prioritizes the hardware driver, which
> > > is a desirable behavior. I'm trying to understand the potential issues that
> > > might arise if VKMS were not excluded in other contexts.
> > >
> > > Thank you!
> > > Mark
> > >
> > >
> > > On Thu, Oct 9, 2025 at 12:46 PM Kamil Konieczny <
> > > kamil.konieczny@linux.intel.com> wrote:
> > >
> > > > Hi Mark,
> > > > On 2025-10-08 at 12:02:09 -0400, Mark Yacoub wrote:
> > > > > [Why]
> > > > > VKMS (Virtual VKMS) is typically running on a virtual machine where it's
> > > > > expected to be without a contention with a hardware driver.
> > > > > When it's there, we would like to run IGT on it.
> > > > >
> > > > > [How]
> > > > > Delete VKMS from DRIVER_ANY's exclusion list to allow IGT to be picked
> > > > > up.
> > > > >
> > > > > Tested: Ran kms_bw on Android's VM with VKMS enabled.
> > > > >
> > > > > Change-Id: Ib13ad9261b8c2617370c02d0ffb5aa878bf3d8f8
> > > > > Signed-off-by: Mark Yacoub <markyacoub@google.com>
> > > > > ---
> > > > > lib/drmtest.h | 4 +---
> > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > > > > index 8416aa491..ab991da57 100644
> > > > > --- a/lib/drmtest.h
> > > > > +++ b/lib/drmtest.h
> > > > > @@ -63,10 +63,8 @@ int __get_drm_device_name(int fd, char *name, int
> > > > name_size);
> > > > > * on a system with them as well as a supported driver, you can end up
> > > > > * with a near-100% skip rate if you don't explicitly specify the
> > > > device,
> > > > > * depending on device-load ordering.
> > > > > - *
> > > > > - * Exclude VKMS to prefer hardware drivers.
> > > > > */
> > > > > -#define DRIVER_ANY ~(DRIVER_VGEM | DRIVER_VKMS | DRIVER_VIRTIO)
> > > > > +#define DRIVER_ANY ~(DRIVER_VGEM | DRIVER_VIRTIO)
> > > >
> > > > Nak, this is bad as there could be vkms module also on host.
> > > >
> > > > Let me work on improving IGT_FORCE_DRIVER.
> > > >
> > > > Regards,
> > > > Kamil
> > > >
> > > > >
> > > > > /*
> > > > > * Compile friendly enum for i915/xe.
> > > > > --
> > > > > 2.51.0.740.g6adb054d12-goog
> > > > >
> > > >
>
> --
> --
> Louis Chauvet, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
next prev parent reply other threads:[~2025-10-16 11:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 16:02 [PATCH i-g-t] lib/drmtest: Remove VKMS from Exclusion list Mark Yacoub
2025-10-08 20:26 ` ✓ Xe.CI.BAT: success for " Patchwork
2025-10-08 20:39 ` ✓ i915.CI.BAT: " Patchwork
2025-10-08 23:55 ` ✓ Xe.CI.Full: " Patchwork
2025-10-09 10:20 ` ✗ i915.CI.Full: failure " Patchwork
2025-10-09 16:46 ` [PATCH i-g-t] " Kamil Konieczny
2025-10-09 16:53 ` Mark Yacoub
2025-10-14 14:46 ` Mark Yacoub
2025-10-15 18:16 ` Kamil Konieczny
2025-10-16 8:40 ` Louis Chauvet
2025-10-16 11:00 ` José Expósito [this message]
2025-10-16 14:51 ` Mark Yacoub
2025-10-16 17:53 ` José Expósito
2025-10-24 9:47 ` Kamil Konieczny
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=aPDQOgFtR0aMo4_C@fedora \
--to=jose.exposito89@gmail.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=juhapekka.heikkila@gmail.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=louis.chauvet@bootlin.com \
--cc=markyacoub@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox