smbios: Search for v3 (64-bit) table before v2 (32-bit) on BIOS boot

[olce]

Summary

When booted from BIOS (i.e., not EFI), also search for a 64-bit version
of the SMBIOS Entry Point.

This allows us to detect and report the proper SMBIOS version with
BIOSes that only provide the v3 table, as happens on Hetzner virtual
machines.

For machines that provide both, leverage the v3 table in priority.

While here, when attaching, in addition to the version contained in the
table, print whether the v3 (64-bit) or v2 (32-bit) table was used.

PR: 284460
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation

Test Plan

• Tested in a VirtualBox VM that only provides the 32-bit table.
• Will test on hardware providing the 64-bit table.
• Patch attached to the PR, to have the reporter test it and report what smbios(4) spits in the logs.

[markj]

PR: 284460

Presumably this won't actually fix the reported problem, since the BIOS loader needs to be updated as well?

[imp]

These are fine, but largely irrelevant since the in kernel smbios driver doesn't do much

[imp]

Oopps wrong button on phone

[olce]

In D49179#1121925, @markj wrote:

PR: 284460

Presumably this won't actually fix the reported problem, since the BIOS loader needs to be updated as well?

Yes. As said during the call and in the bug, the smbios kenv variables are filled in by the loader, which has nothing to do with the kernel's smbios(4) driver.

However, I don't see why the loader doesn't detect the 64-bit SMBIOS table, which presumably is present given what the user reported. HAS_SMBV3 is indeed automatically defined on 64-bit architectures. I've asked for more information (please see my comment in the bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284460#c1.)

The main point in doing the change here is to get better diagnostics about whether the 64-bit table was detected or not, and why (no signature? checksum? etc.). It's also better that the loader and kernel driver are somewhat in sync (although the loader currently will try to find a 32-bit table first, even if a 64-bit is present; I should probably change that).

In D49179#1121927, @imp wrote:

These are fine, but largely irrelevant since the in kernel smbios driver doesn't do much

Yes, thanks, I'm already aware (please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284460#c1).

[olce]

In D49179#1122325, @olce wrote:

Yes. As said during the call and in the bug, the smbios kenv variables are filled in by the loader, which has nothing to do with the kernel's smbios(4) driver.

Oh, after more reading, I now know what is wrong in the loader. Will post other reviews in a while.

[markj]

In D49179#1122329, @olce wrote:

In D49179#1122325, @olce wrote:

Yes. As said during the call and in the bug, the smbios kenv variables are filled in by the loader, which has nothing to do with the kernel's smbios(4) driver.

Oh, after more reading, I now know what is wrong in the loader. Will post other reviews in a while.

Is it that the bios loader isn't a 64-bit binary?

[olce]

In D49179#1122345, @markj wrote:

Is it that the bios loader isn't a 64-bit binary?

Didn't notice this one. I will definitely test whether HAS_SMBV3 is defined or not as part of smoke tests. The problem I spotted is that the loader doesn't seem to parse the SMBIOS tables beyond the entry point in the v3 (64 bit) case, and I'm working on changing that at the moment.

[imp]

In D49179#1122373, @olce wrote:

In D49179#1122345, @markj wrote:

Is it that the bios loader isn't a 64-bit binary?

Didn't notice this one. I will definitely test whether HAS_SMBV3 is defined or not as part of smoke tests. The problem I spotted is that the loader doesn't seem to parse the SMBIOS tables beyond the entry point in the v3 (64 bit) case, and I'm working on changing that at the moment.

The BIOS loader is indeed a 32-bit binary. So

/* Only enable 64-bit entry point if it makes sense */
#if SIZEOF_POINTER > 4
#define HAS_SMBV3 1
#endif

will evaluate to having it undefined. I think that the 64-bit pointers can't be accessed
that are present in the V3 structure.

The problem comes in smbios_probe where use fetch the 64-bit paddr for the table.
It won't fit in a 32-bit pointer. Unfortunately, usually you either have a V3 or a V2
structure (but not both). I could check to see if the upper bits are set and only ignore
it in that case for the above condition.