|
On 09/24/2015 07:23 AM, Dave Gordon
wrote:
On 22/09/15 21:48, yu.dai@xxxxxxxxx wrote: > From: Alex Dai <yu.dai@xxxxxxxxx> > > By using information from GuC css header, we can eliminate some > hard code w.r.t size of some components of firmware. > > v2: Add indent into DOC to make fixed-width format rather than > change the tmpl. > > v1: 1) guc_css_header is defined as __packed now > 2) Add and correct GuC related topics in kernel/Doc > > Signed-off-by: Alex Dai <yu.dai@xxxxxxxxx> > --- > Documentation/DocBook/drm.tmpl | 9 ++- > drivers/gpu/drm/i915/intel_guc.h | 2 +- > drivers/gpu/drm/i915/intel_guc_fwif.h | 36 +++++++++++ > drivers/gpu/drm/i915/intel_guc_loader.c | 107 ++++++++++++++++++++++---------- > 4 files changed, 117 insertions(+), 37 deletions(-) > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl > index 66bc646..116332f 100644 > --- a/Documentation/DocBook/drm.tmpl > +++ b/Documentation/DocBook/drm.tmpl > @@ -4155,14 +4155,19 @@ int num_ioctls;</synopsis> > <title>GuC-based Command Submission</title> > <sect2> > <title>GuC</title> > -!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader > +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC > !Idrivers/gpu/drm/i915/intel_guc_loader.c > </sect2> > <sect2> > <title>GuC Client</title> > -!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison > +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC Client > !Idrivers/gpu/drm/i915/i915_guc_submission.c > </sect2> > + <sect2> > + <title>GuC Firmware Layout</title> > +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC Firmware Layout > +!Idrivers/gpu/drm/i915/intel_guc_loader.c > + </sect2> > </sect1> > > <sect1> > diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h > index 4ec2d27..e1389fc 100644 > --- a/drivers/gpu/drm/i915/intel_guc.h > +++ b/drivers/gpu/drm/i915/intel_guc.h > @@ -71,6 +71,7 @@ struct intel_guc_fw { > struct drm_i915_gem_object * guc_fw_obj; > enum intel_guc_fw_status guc_fw_fetch_status; > enum intel_guc_fw_status guc_fw_load_status; > + struct guc_css_header guc_fw_header; > > uint16_t guc_fw_major_wanted; > uint16_t guc_fw_minor_wanted; > @@ -80,7 +81,6 @@ struct intel_guc_fw { > > struct intel_guc { > struct intel_guc_fw guc_fw; > - > uint32_t log_flags; > struct drm_i915_gem_object *log_obj; > > diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h > index e1f47ba..006dc0d 100644 > --- a/drivers/gpu/drm/i915/intel_guc_fwif.h > +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h > @@ -122,6 +122,42 @@ > > #define GUC_CTL_MAX_DWORDS (GUC_CTL_RSRVD + 1) > > +struct guc_css_header { > + uint32_t module_type; > + uint32_t header_len; /* header length plus size of all other keys */ > + uint32_t header_version; > + uint32_t module_id; > + uint32_t module_vendor; > + union { > + struct { > + uint8_t day; > + uint8_t month; > + uint16_t year; > + }; > + uint32_t date; > + }; > + uint32_t size; /* uCode size plus header_len */ > + uint32_t key_size; > + uint32_t modulus_size; > + uint32_t exponent_size; > + union { > + struct { > + uint8_t hour; > + uint8_t min; > + uint16_t sec; > + }; > + uint32_t time; > + }; > + > + char username[8]; > + char buildnumber[12]; > + uint32_t device_id; > + uint32_t guc_sw_version; > + uint32_t prod_preprod_fw; > + uint32_t reserved[12]; > + uint32_t header_info; > +} __packed; > + > struct guc_doorbell_info { > u32 db_status; > u32 cookie; > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c > index 40241f3..a6703b4 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -215,18 +215,29 @@ static inline bool guc_ucode_response(struct drm_i915_private *dev_priv, > ((val & GS_MIA_CORE_STATE) && uk_val == GS_UKERNEL_LAPIC_DONE)); > } > > -/* > - * Transfer the firmware image to RAM for execution by the microcontroller. > +/** > + * DOC: GuC Firmware Layout > * > - * GuC Firmware layout: > - * +-------------------------------+ ---- > - * | CSS header | 128B > - * | contains major/minor version | > - * +-------------------------------+ ---- > - * | uCode | > - * +-------------------------------+ ---- > - * | RSA signature | 256B > - * +-------------------------------+ ---- > + * The GuC firmware layout looks like this: > + * > + * +-------------------------------+ > + * | guc_css_header | > + * | contains major/minor version | > + * +-------------------------------+ > + * | uCode | > + * +-------------------------------+ > + * | RSA signature | > + * +-------------------------------+ > + * | modulus key | > + * +-------------------------------+ > + * | exponent val | > + * +-------------------------------+ > + * > + * The firmware may or may not have modulus key and exponent data. The header, > + * uCode and RSA signature are must-have components that will be used by driver. > + * Size of each components (in dwords) can be found in header. In the case that > + * modulus and exponent are not present in fw, the size value still appears in > + * header. I think this picture & commentary belongs just ahead of the structure definition in intel_guc_fwif.h, rather than with the code here. Also, Yes, this can be moved to intel_guc_fwif.h right before css_header structure definition. perhaps we nede a bit more explanation of the '*size' fields, since they have been defined in such a counter-intuitive way :( I suggest: * All the 'sizes' in the CSS header are expressed as numbers of * "dwords", and therefore have to be multiplied by sizeof (u32) to * get actual sizes (in the normal sense of byte counts). * In comments, I clearly mention that all size of these guc components are in dwords. In next version, I can add surfix _dword to avoid confuse. * The 'size' field is the total size of the data in the picture * above, and should match the size of the file as provided by the * loader; the file is invalid if this size field is greater than * the actual filesize. This is not right assumption. And, that will change some expectation below related to size checking. I should have make my comments more clear. But "The firmware may or may not have modulus key and exponent data ... In the case that modulus and exponent are not present in fw, the size value still appears in header."We have discussed this with firmware team. Since the 'size' (actually the header) is used to generate RSA key, we can't change it after signing. So, we have information of modulus etc. but driver doesn't need them to load firmware. Likely they are not part of the release bin file. So the 'size' may be larger than the bin file size. Currently, fw check is based on the following rules (maybe I need add these to the comment too):
* * The 'header_len' field contains the total size of the non-uCode * sections of the file (i.e. the sum of the sizes of the CSS header, * the RSA signature, the modulus key and the exponent). Thus, to find * the size of the uCode we subtract this total from 'size', but to * find the size of the CSS header (which also defines the start of * the uCode), we subtract the other three sizes from this total. The * size of the CSS header thus calculated should match sizeof(struct * guc_css_header) (or exceed it; allowing it to be larger permits * future expansion of the CSS header or insertion of extra sections * here). The file is invalid if this calculated size is less than * sizeof(struct guc_css_header). * * The size of the RSA signature must not exceed that expected by the * hardware. The file is invalid if the value of this field is more * than the size of the signature area in the GuC register space, * currently 0x100 bytes. * * Due to the requirements of the DMA engine, the total size of the * sections that are DMA'd into the GuC's memory (CSS header plus * uCode) must be a multiple of the cache line size. The file is * invalid if this requirement is not met. All suggestions above are valid at some points. However, be note that, the firmware size checking I put into code is actually to protect driver - just make sure we don't have a bug check due to memory access violation. No matter how much protection you put into driver, you still can't reject the case by driver if someone modifies one byte of uCode. So, as long as we have the bits of header, uCode and RSA, we will load it. HW will fail it anyway if anything goes wrong.
This is a good point.
I only agree with check between header size and fw size. This allows driver keeps going without bug check. All others between members within css_header are not needed. The reason is simple. If you trust content of css_header, then you don't need to validate them. If you don't trust it, no need to check it anyway. Again, as long as we have enough bits to load to HW, we will let it go. Thanks, Alex |
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
