From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: "Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Lucas De Marchi" <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [CI] HAX: Try SR-IOV on ADLP/ATSM
Date: Fri, 28 Jun 2024 22:22:07 +0200 [thread overview]
Message-ID: <61ccf2a7-290e-4eec-86eb-bada852e1e6d@intel.com> (raw)
In-Reply-To: <Zn8GQZo5Qh8oHvIn@intel.com>
On 28.06.2024 20:51, Rodrigo Vivi wrote:
> On Mon, Jun 24, 2024 at 02:02:03PM +0200, Michal Wajdeczko wrote:
>> This is for CI only. DO NOT REVIEW. DO NOT MERGE.
>
> how are these tests looking like at this moment?
IMO quite good
recent run [1] just uncovered two existing issues that actually are not
related to the Xe SR-IOV code:
first problem [2]:
Starting dynamic subtest: vf-2
(sriov_basic:1395) igt_device-WARNING: Couldn't find PCI device
0000:00:02:02
was due to a test bug, attempt to fix that is under review [3]
second problem [4]:
<7> [259.552619] BUG: MAX_LOCKDEP_KEYS too low!
<7> [259.552626] turning off the locking correctness validator.
was reproduced on driver running in non-SRIOV mode (native), not sure
whether public bug was created for it, though
[1]
https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-135295v2/index.html?testfilter=iov
[2]
https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-135295v2/shard-adlp-2/igt@sriov_basic@bind-unbind-vf.html
[3] https://patchwork.freedesktop.org/series/135476/
[4]
https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-135295v2/shard-adlp-1/igt@sriov_basic@enable-vfs-autoprobe-on.html#dmesg-warnings1677
> I'm wondering if it is already time to add this patch to topic/xe-for-CI
it would be great, as this patch allows running few basic SR-IOV tests
(including VF driver probe) on the existing BAT/FULL CI runs, so with
minimal effort we will be able to catch regressions/breaks that impacts
the VF driver.
note that being a PF driver by default shouldn't impact any existing
results or functionality, as any resources needed for VFs are reserved
only when VFs are enable during the SR-IOV tests.
additional resources used by the PF until VF are enabled are negligible
>
> Thomas? Lucas? thoughts?
>
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_module.c | 1 +
>> drivers/gpu/drm/xe/xe_pci.c | 2 ++
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_module.c b/drivers/gpu/drm/xe/xe_module.c
>> index 893858a2eea0..c0cf3b8ad815 100644
>> --- a/drivers/gpu/drm/xe/xe_module.c
>> +++ b/drivers/gpu/drm/xe/xe_module.c
>> @@ -18,6 +18,7 @@ struct xe_modparam xe_modparam = {
>> .enable_display = true,
>> .guc_log_level = 5,
>> .force_probe = CONFIG_DRM_XE_FORCE_PROBE,
>> + .max_vfs = IS_ENABLED(CONFIG_DRM_XE_DEBUG) ? ~0 : 0,
>> .wedged_mode = 1,
>> /* the rest are 0 by default */
>> };
>> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
>> index ebff5ea79b1d..488a444b7b5c 100644
>> --- a/drivers/gpu/drm/xe/xe_pci.c
>> +++ b/drivers/gpu/drm/xe/xe_pci.c
>> @@ -261,6 +261,7 @@ static const struct xe_device_desc adl_p_desc = {
>> { XE_SUBPLATFORM_ALDERLAKE_P_RPLU, "RPLU", adlp_rplu_ids },
>> {},
>> },
>> + .has_sriov = IS_ENABLED(CONFIG_DRM_XE_DEBUG),
>> };
>>
>> static const struct xe_device_desc adl_n_desc = {
>> @@ -307,6 +308,7 @@ static const struct xe_device_desc ats_m_desc = {
>>
>> DG2_FEATURES,
>> .has_display = false,
>> + .has_sriov = IS_ENABLED(CONFIG_DRM_XE_DEBUG),
>> };
>>
>> static const struct xe_device_desc dg2_desc = {
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2024-06-28 20:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 12:02 [CI] HAX: Try SR-IOV on ADLP/ATSM Michal Wajdeczko
2024-06-24 12:36 ` ✓ CI.Patch_applied: success for " Patchwork
2024-06-24 12:36 ` ✓ CI.checkpatch: " Patchwork
2024-06-24 12:38 ` ✓ CI.KUnit: " Patchwork
2024-06-24 12:50 ` ✓ CI.Build: " Patchwork
2024-06-24 12:52 ` ✗ CI.Hooks: failure " Patchwork
2024-06-24 12:53 ` ✓ CI.checksparse: success " Patchwork
2024-06-24 13:16 ` ✓ CI.BAT: " Patchwork
2024-06-24 15:16 ` ✗ CI.FULL: failure " Patchwork
2024-06-28 18:51 ` [CI] " Rodrigo Vivi
2024-06-28 20:22 ` Michal Wajdeczko [this message]
2024-06-28 20:58 ` Lucas De Marchi
2024-07-01 11:00 ` Michal Wajdeczko
2024-07-02 16:02 ` Thomas Hellström
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=61ccf2a7-290e-4eec-86eb-bada852e1e6d@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.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.