Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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