[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f279cfe-c3b0-44d2-9bcd-82662058d9c3@intel.com>
Date: Mon, 3 Nov 2025 19:55:08 +0100
From: Michal Wajdeczko <michal.wajdeczko@...el.com>
To: Michał Winiarski <michal.winiarski@...el.com>, "Alex
Williamson" <alex@...zbot.org>, Lucas De Marchi <lucas.demarchi@...el.com>,
Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@...el.com>, Jason Gunthorpe <jgg@...pe.ca>,
Yishai Hadas <yishaih@...dia.com>, Kevin Tian <kevin.tian@...el.com>, Shameer
Kolothum <skolothumtho@...dia.com>, <intel-xe@...ts.freedesktop.org>,
<linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>, Matthew Brost
<matthew.brost@...el.com>
CC: <dri-devel@...ts.freedesktop.org>, Jani Nikula
<jani.nikula@...ux.intel.com>, Joonas Lahtinen
<joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin <tursulin@...ulin.net>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, "Lukasz
Laguna" <lukasz.laguna@...el.com>, Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v3 02/28] drm/xe: Move migration support to device-level
struct
On 10/30/2025 9:31 PM, Michał Winiarski wrote:
> Upcoming changes will allow users to control VF state and obtain its
> migration data with a device-level granularity (not tile/gt).
> Change the data structures to reflect that and move the GT-level
> migration init to happen after device-level init.
>
> Signed-off-by: Michał Winiarski <michal.winiarski@...el.com>
> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@...el.com>
> ---
...
> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_migration_types.h b/drivers/gpu/drm/xe/xe_sriov_pf_migration_types.h
> new file mode 100644
> index 0000000000000..e69de29bb2d1d
> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_types.h b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> index c753cd59aed2b..24d22afeececa 100644
> --- a/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> +++ b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> @@ -39,6 +39,12 @@ struct xe_device_pf {
> /** @provision: device level provisioning data. */
> struct xe_sriov_pf_provision provision;
>
> + /** @migration: device level VF migration data */
> + struct {
> + /** @migration.supported: indicates whether VF migration feature is supported */
> + bool supported;
> + } migration;
> +
late notice: all our other sub-components (except sysfs *) to hold its private fields define its own struct that matches component name
but here, you use anonymous struct instead and what worse,
later on you start using xe_sriov_pf_migration name to hold per-VF data,
which breaks the above naming pattern even more
can you add to xe_sriov_pf_migration_types.h:
+struct xe_sriov_pf_migration {
+ /** @supported: indicates whether VF migration feature is supported */
+ bool supported;
+};
and rename per-VF struct to something else? like:
struct xe_sriov_migration_state - Per VF device-level migration related data
*) sysfs doesn't define/use any custom data types, just kobject
> /** @service: device level service data. */
> struct xe_sriov_pf_service service;
>
Powered by blists - more mailing lists