[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 1/1] hvmloader: allow overriding SMBIOS type 2 info



Hi Jan,
    Thanks for reviewing.

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, March 26, 2019 9:15 PM
> To: Xin Li <talons.lee@xxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Igor Druzhinin
> <igor.druzhinin@xxxxxxxxxx>; Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>; Xin Li
> (Talons) <xin.li@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v1 1/1] hvmloader: allow overriding SMBIOS
> type 2 info
> 
> >>> On 26.03.19 at 07:45, <talons.lee@xxxxxxxxx> wrote:
> > Extend smbios type 2 struct to match specification, add support to
> > override strings from toolstack.
> >
> > Signed-off-by: Xin Li <xin.li@xxxxxxxxxx>
> >
> > ---
> > CC: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> > CC: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
> > CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 
> I wonder why I have not been Cc-ed.
Sorry, adding you.

> 
> > @@ -518,7 +520,67 @@ smbios_type_2_init(void *start)
> >          return (start + length);
> >      }
> 
> In the subject you say "overriding", but you add new information only when
> it couldn't be found via get_smbios_pt_struct(). Which in turn already is sort
> of tool stack provided, so a means to override things already exists. Please
> clarify this in title and/or description.
OK. how about:

    hvmloader: add SMBIOS type 2 info for customized string
    
    Extend smbios type 2 struct to match specification, add support to
    write it when customized string provided and no smbios passed in.

> 
> > -    /* Only present when passed in */
> > +    s = xenstore_read(HVM_XS_BASEBOARD_MANUFACTURER, NULL);
> > +    if ( (s != NULL) && (*s != '\0') )
> 
> Is it really a good idea to key everything else off of the presence of this 
> one
> string in xenstore? Shouldn't it rather be that the structure gets 
> instantiated
> whenever any of the strings are there?
OK.
I wanted to avoid structure without manufacturer,
the app we met only read this field.

Can I iterate the 6 keys twice?
first iteration to decide if any string is provided,
the second iteration to initialize structure. 

> 
> > +    {
> > +        memset(p, 0, sizeof(*p));
> > +        p->header.type = 2;
> > +        p->header.length = sizeof(struct smbios_type_2);
> > +        p->header.handle = SMBIOS_HANDLE_TYPE2;
> > +        p->feature_flags = 0x09; /* Board is a hosting board and
> > + replaceable */
> 
> Doesn't setting bit 3 sort of imply also setting bit 2? Yet do we really mean 
> to
> mark the board as replaceable in the first place?
For the hosts I've checked, bit 3 is set but bit 2 isn't.

> 
> > +        p->chassis_handle = SMBIOS_HANDLE_TYPE3;
> > +        p->board_type = 0x0a; /* Motherboard */
> > +        start += sizeof(struct smbios_type_2);
> > +
> > +        strcpy((char *)start, s);
> 
> There's at least one example in smbios_type_3_init() showing that casts like
> this one aren't needed.
OK. Will remove this unnecessary cast for void*.

> 
> > --- a/tools/firmware/hvmloader/smbios_types.h
> > +++ b/tools/firmware/hvmloader/smbios_types.h
> > @@ -90,6 +90,12 @@ struct smbios_type_2 {
> >      uint8_t product_name_str;
> >      uint8_t version_str;
> >      uint8_t serial_number_str;
> > +    uint8_t asset_tag_str;
> > +    uint8_t feature_flags;
> > +    uint8_t location_in_chassis_str;
> > +    uint16_t chassis_handle;
> > +    uint8_t board_type;
> > +    uint8_t contained_handle_count;
> 
>     uint16_t contained_handles[];
Sure. Adding this.

> 
> > --- a/xen/include/public/hvm/hvm_xs_strings.h
> > +++ b/xen/include/public/hvm/hvm_xs_strings.h
> > @@ -62,18 +62,24 @@
> >  /* The following xenstore values are used to override some of the default
> >   * string values in the SMBIOS table constructed in hvmloader.
> >   */
> > -#define HVM_XS_BIOS_STRINGS            "bios-strings"
> > -#define HVM_XS_BIOS_VENDOR             "bios-strings/bios-vendor"
> > -#define HVM_XS_BIOS_VERSION            "bios-strings/bios-version"
> > -#define HVM_XS_SYSTEM_MANUFACTURER     "bios-strings/system-
> manufacturer"
> > -#define HVM_XS_SYSTEM_PRODUCT_NAME     "bios-strings/system-
> product-name"
> > -#define HVM_XS_SYSTEM_VERSION          "bios-strings/system-version"
> > -#define HVM_XS_SYSTEM_SERIAL_NUMBER    "bios-strings/system-serial-
> number"
> > -#define HVM_XS_ENCLOSURE_MANUFACTURER  "bios-strings/enclosure-
> manufacturer"
> > -#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-
> serial-number"
> > -#define HVM_XS_ENCLOSURE_ASSET_TAG     "bios-strings/enclosure-
> asset-tag"
> > -#define HVM_XS_BATTERY_MANUFACTURER    "bios-strings/battery-
> manufacturer"
> > -#define HVM_XS_BATTERY_DEVICE_NAME     "bios-strings/battery-
> device-name"
> > +#define HVM_XS_BIOS_STRINGS                  "bios-strings"
> > +#define HVM_XS_BIOS_VENDOR                   "bios-strings/bios-vendor"
> > +#define HVM_XS_BIOS_VERSION                  "bios-strings/bios-version"
> > +#define HVM_XS_SYSTEM_MANUFACTURER           "bios-strings/system-
> manufacturer"
> > +#define HVM_XS_SYSTEM_PRODUCT_NAME           "bios-strings/system-
> product-name"
> > +#define HVM_XS_SYSTEM_VERSION                "bios-strings/system-
> version"
> > +#define HVM_XS_SYSTEM_SERIAL_NUMBER          "bios-strings/system-
> serial-number"
> > +#define HVM_XS_BASEBOARD_MANUFACTURER        "bios-
> strings/baseboard-manufacturer"
> > +#define HVM_XS_BASEBOARD_PRODUCT_NAME        "bios-
> strings/baseboard-product-name"
> > +#define HVM_XS_BASEBOARD_VERSION             "bios-strings/baseboard-
> version"
> > +#define HVM_XS_BASEBOARD_SERIAL_NUMBER       "bios-
> strings/baseboard-serial-number"
> > +#define HVM_XS_BASEBOARD_ASSET_TAG           "bios-
> strings/baseboard-asset-tag"
> > +#define HVM_XS_BASEBOARD_LOCATION_IN_CHASSIS "bios-
> strings/baseboard-location-in-chassis"
> > +#define HVM_XS_ENCLOSURE_MANUFACTURER        "bios-
> strings/enclosure-manufacturer"
> > +#define HVM_XS_ENCLOSURE_SERIAL_NUMBER       "bios-
> strings/enclosure-serial-number"
> > +#define HVM_XS_ENCLOSURE_ASSET_TAG           "bios-strings/enclosure-
> asset-tag"
> > +#define HVM_XS_BATTERY_MANUFACTURER          "bios-strings/battery-
> manufacturer"
> > +#define HVM_XS_BATTERY_DEVICE_NAME           "bios-strings/battery-
> device-name"
> 
> To be honest I'd prefer if you avoided the re-formatting, accepting the one
> definition that then doesn't properly align with the rest. But if others think
> differently, so be it.
Can I keep this style? This seems fit current code style.

> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.