On Fri, Nov 11, 2022 at 10:48:49AM -0800, Dave Hansen wrote:
> On 11/11/22 10:39, Borislav Petkov wrote:
> >> +struct meta_data {
> >> + unsigned int meta_type; // metadata type
> >> + unsigned int meta_size; // size of this entire struct including hdrs.
> >> + unsigned int test_type; // IFS test type
> >> + unsigned int fusa_info; // Fusa info
> >> + unsigned int total_images; // Total number of images
> >> + unsigned int current_image; // Current Image #
> >> + unsigned int total_chunks; // Total number of chunks in this image
> >> + unsigned int starting_chunk; // Starting chunk number in this image
> >> + unsigned int size_per_chunk; // size of each chunk
> >> + unsigned int chunks_per_stride; // number of chunks in a stride
> >> + unsigned int reserved[54]; // Align to 256 bytes for chunk alignment.
> > That looks weird.
> >
> > __packed and __aligned doesn't work?
>
> ... and don't we try to use fixed-size typed in hardware structures,
> like u32?
Maybe should we do a cleanup patch to move struct microcode_header_intel
also to u32 format then add meta_data to follow the same style?
When we defined struct meta_data followed the format and style that was
already in place.
The suggestion below is a lot nicer, let the compiler do te job.
>
> There are also much nicer ways to do this:
>
> union meta_data {
> struct {
> u32 meta_type; // metadata type
> u32 meta_size; // size of ...
> };
> u8 padding[IFS_CHUNK_ALIGNMENT];
> }
>
> That doesn't have any magic linkage between the magic "54" (times 4) and
> IFS_CHUNK_ALIGNMENT. It makes the compiler do the hard work for you.
>
> Voila, you have a union that's always IFS_CHUNK_ALIGNMENT in size, No
> magic 54's necessary.
