From: "Xin Li (Talons)" <xin.li@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xin Li <talons.lee@gmail.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
Sergey Dyasli <sergey.dyasli@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Igor Druzhinin <igor.druzhinin@citrix.com>
Subject: Re: [PATCH v1 1/1] hvmloader: allow overriding SMBIOS type 2 info
Date: Wed, 27 Mar 2019 10:54:17 +0000 [thread overview]
Message-ID: <1553684057486.68231@citrix.com> (raw)
In-Reply-To: <5C9A25EE0200007800221EA9@prv1-mh.provo.novell.com>
Hi Jan,
Thanks for reviewing.
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, March 26, 2019 9:15 PM
> To: Xin Li <talons.lee@gmail.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Igor Druzhinin
> <igor.druzhinin@citrix.com>; Sergey Dyasli <sergey.dyasli@citrix.com>; Xin Li
> (Talons) <xin.li@citrix.com>; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v1 1/1] hvmloader: allow overriding SMBIOS
> type 2 info
>
> >>> On 26.03.19 at 07:45, <talons.lee@gmail.com> wrote:
> > Extend smbios type 2 struct to match specification, add support to
> > override strings from toolstack.
> >
> > Signed-off-by: Xin Li <xin.li@citrix.com>
> >
> > ---
> > CC: Igor Druzhinin <igor.druzhinin@citrix.com>
> > CC: Sergey Dyasli <sergey.dyasli@citrix.com>
> > CC: Andrew Cooper <andrew.cooper3@citrix.com>
>
> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-03-27 10:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 6:45 [PATCH v1 1/1] hvmloader: allow overriding SMBIOS type 2 info Xin Li
2019-03-26 13:15 ` Jan Beulich
2019-03-27 10:54 ` Xin Li (Talons) [this message]
2019-03-27 11:23 ` Jan Beulich
2019-03-27 12:22 ` Xin Li (Talons)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1553684057486.68231@citrix.com \
--to=xin.li@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=igor.druzhinin@citrix.com \
--cc=sergey.dyasli@citrix.com \
--cc=talons.lee@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.