bhyve: use bhyve_config for SMBIOS strings

[corvink]

Summary

Some software uses SMBIOS entries to identify the system on which it's
running. In order to make it possible to use such software inside a VM,
SMBIOS entries should be configurable. Therefore, bhyve_config can be
used. While only a few SMBIOS entries might be of interest, it makes
sense that all SMBIOS entries are configurable. This way all SMBIOS
tables are build the same way and there's no special handling for some
tables.

[corvink]

• keep old variable names to make the diff smaller

[jhb]

Hmmm, do we know if users expect to set all of these vs just the system serial number? I'm not opposed to making these all configurable, per se, but part of the reason I had suggested "serial_number" as a more abstract thing is that we might reuse that same value to populate a serial number field in other places (e.g. in ACPI tables perhaps or FDT for some other non-x86 architecture)

[corvink]

I've mainly decided to make all values configurable to avoid a special handling for single values. Additionally, I don't know if just serial_number makes sense. There's system.serial_number, board.serial_number, chassis.serial_number, ... What about using " " for unmodifiable nodes? e.g.

struct smbios_string smbios_type1_strings[] = {
	{ " ", "FreeBSD" },			/* manufacturer string */
	{ " ", "BHYVE" },			/* product string */
	{ " ", "1.0" },				/* version string */
	{ "system.serial_number", "None" },	/* serial number string */
	{ " ", "None" },			/* sku string */
	{ " ", "Virtual Machine" },		/* family string */
	{ 0 }
};

[jhb]

usr.sbin/bhyve/smbiostbl.c

526

These are perhaps the ones that seem a bit odd to me, but it's probably fine to just permit configuring them. (I guess partly because as with the processor strings, there could in theory be multiple of these entries in a table. In real systems you often do have multiple of both.)

If we wanted to have an opt-out I would prefer to use NULL I think and depend on checking the second member for NULL to terminate loops instead of checking the first member.

[corvink]

• make processor and memdevice strings unconfigurable

[andy_omniosce.org]

Thanks for doing this, we have something similar in the illumos port, although only for the type1 strings (https://man.omnios.org/bhyve.8#B), and the config keys are different (but I can add translators for backwards compatibility when I port this over).

In illumos, it is split up into two phases, one that parses and one that does the smbios build. This means that the keys and values show up with -o config.dump=1, which I think is useful as it provides a template for editing.
Have you considered doing something like that here?

[corvink]

In D34465#784879, @andy_omniosce.org wrote:

In illumos, it is split up into two phases, one that parses and one that does the smbios build. This means that the keys and values show up with -o config.dump=1, which I think is useful as it provides a template for editing.
Have you considered doing something like that here?

In general, -o config.dump=1 shows only options which are set by the user. There are just a few exceptions set by set_defaults. I have no strong feelings about it. I would like know what others think about it.

[jhb]

I think this is fine. It's true that we currently don't populate the config dump with default values in general. I could see the value in having some way to do that, but that is orthogonal to this change I think.