[Intel-xe] [PATCH v3 27/30] drm/xe: Extend uAPI to query HuC micro-controler firmware version

Souza, Jose jose.souza at intel.com
Wed Sep 27 17:22:32 UTC 2023


+ John Harrison

On Wed, 2023-09-27 at 13:04 -0400, Rodrigo Vivi wrote:
> On Tue, Sep 26, 2023 at 04:46:36PM +0000, Souza, Jose wrote:
> > On Tue, 2023-09-26 at 12:55 +0000, Francois Dugast wrote:
> > > The infrastructure to query GuC firmware version is already in place. It
> > > is extended with a new micro-controller type to query the HuC firmware
> > > version. It can be used from user space to know if HuC is running.
> > > 
> > > Signed-off-by: Francois Dugast <francois.dugast at intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_query.c | 9 +++++++++
> > >  include/uapi/drm/xe_drm.h     | 1 +
> > >  2 files changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_query.c b/drivers/gpu/drm/xe/xe_query.c
> > > index 7a0ffd9a654a..c250ca534bb9 100644
> > > --- a/drivers/gpu/drm/xe/xe_query.c
> > > +++ b/drivers/gpu/drm/xe/xe_query.c
> > > @@ -530,6 +530,15 @@ query_uc_fw_version(struct xe_device *xe, struct drm_xe_device_query *query)
> > >  		resp.branch_ver = 0;
> > >  		break;
> > >  	}
> > > +	case XE_QUERY_UC_TYPE_HUC: {
> > > +		struct xe_huc *huc = &xe->tiles[0].primary_gt->uc.huc;
> > > +
> > > +		resp.major_ver = huc->fw.major_ver_found;
> > > +		resp.minor_ver = huc->fw.minor_ver_found;
> > > +		resp.patch_ver = huc->fw.patch_ver_found;
> > 
> > Have you confirmed that HuC will not have something like submission version like GuC have?
> 
> Nah... GuC is the only complicated fw in our set of fw...
> 
> > At least in GuC, when running in SRIOV mode the VFs will not have access to the actual GuC version, that is why it have submission version.
> > 
> > Not sure if providing a complete different firmware version from one kernel version to other would be considered a uAPI break...
> 
> hmmm... but now what I'm asking myself is if we shouldn't move the guc one to
> have the current loaded firmware and create a special category for the
> submission version:
> 
> XE_QUERY_UC_TYPE_GUC
> XE_QUERY_UC_TYPE_GUC_SUBMISSION
> XE_QUERY_UC_TYPE_HUC

I don't think any UMD would fetch the actual GUC FW version and risk fail when running under SRIOV VF.
If needed we can map a submission version to a actual version...

> 
> But to be really really honest, there's something really fishy on this
> submission version. Why the VF cannot read the running firmware and
> get the submission version from there?

Got this information from John, he can explain it better.

> 
> > 
> > > +		resp.branch_ver = 0;
> > > +		break;
> > > +	}
> > >  	default:
> > >  		return -EINVAL;
> > >  	}
> > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > > index 84091860c7d2..fe7e83a5bd3e 100644
> > > --- a/include/uapi/drm/xe_drm.h
> > > +++ b/include/uapi/drm/xe_drm.h
> > > @@ -478,6 +478,7 @@ struct drm_xe_query_topology_mask {
> > >  struct drm_xe_query_uc_fw_version {
> > >  	/** @uc: The micro-controller type to query firmware version */
> > >  #define XE_QUERY_UC_TYPE_GUC 0
> > > +#define XE_QUERY_UC_TYPE_HUC 1
> > >  	__u16 uc_type;
> > >  
> > >  	/** @pad: MBZ */
> > 



More information about the Intel-xe mailing list