Here's version 4 of moving smbios table construction into QEMU.
New in this version:
- 9/12 builds all memory tables (16, 17, 19, 20) and IMHO has much
cleaner and easier to understand code, as well as extensive comments
re. how tables fit together, and how they're generated.
- after 10/12, we're 100% bug-for-bug SeaBIOS compatible
- 11/12 updates tables (most importantly type 17) to v2.4 compatibility
by adding the v2.3 fields missing in SeaBIOS
- 12/12 removes bug-for-bug compatibility, cleans up a few of
the arbitrarily hard coded fields, and counts CPUs starting from 0
to match the rest of the table types with multiple instances.
Re. e820: I believe it's premature to build smbios tables from e820.
Both e820 and smbios are currently built from three "primitives":
ram_size, and [below|above]_4g_mem_size, and it is uncertain (at least
to me, at least right now) what e820 will end up looking like in the
future. I would humbly suggest we switch smbios generation over to using
e820 as a source once that becomes clearer.
See below for more e820 related thoughts and questions.
By adding support for the inclusion of a type 2 (baseboard) table, and
by generating v2.4 compliant type 17 (dimm) tables, this patch series
allows QEMU to more or less officially support OS X guests (v10.8 and
later, using Chameleon as a bootloader, but without further out of tree
patches).
On Fri, Mar 14, 2014 at 06:51:05PM +0100, Igor Mammedov wrote:
> They might overlap, grep for e820_add_entry(). If you interested in
> what kernel does with such table look for sanitize_e820_map() there.
I looked, and it appears sanitize_e820_map() will turn whatever is
collected from the hardware into a set of non-overlapping entries.
I am now wondering if QEMU isn't capable of directly generating a
sanitized e820 map from start.
> Does SMBIOS/t17 actually care about shadowing parts of it by something
> else in unrelated e820?
AFAICT, we only care about E820_RAM entries, so that we can map them
to DIMMs representing the total memory (ram_size) configured on the system.
> Once we have DIMMDevices, I'm planning to convert below-4g and above-4g to
> a set of DIMMDevices, there will be at least 1 device per node but there could
> be more of them to satisfy different backend requirements like hugepage
> size, alignment, e.t.c.
>
> BTW why do we care how smbios tables are build in relation to NUMA mapping,
> they seem to be totally independent.
Right now, both the e820 table and smbios tables are populated from the same
set of "primitives", i.e. ram_size, below_4g_mem_size, and above_4g_mem_size.
If, in the future, we decide to build smbios memory tables indirectly, i.e.
from e820 (based on the fact that e820 will contain more complete information
supplied from more than just pc_q35_init() or pc_init1(), if using piix) it
will be good to have an idea of how to programatically deal with whatever
combinations of nodes, DIMMs, etc. will be present. Mainly, how can I tell
if a bunch of E820_RAM entries from the e820 table all belong to the same
or different nodes ?
At this point, can anyone with access to a real, physical, NUMA system dump
the smbios tables with dmidecode and post them here ? I think that would
be very informative.
Thanks again,
--Gabriel
Gabriel L. Somlo (12):
SMBIOS: Rename smbios_set_type1_defaults() for more general use
SMBIOS: Use macro to set smbios defaults
SMBIOS: Use bitmaps to check for smbios table collisions
SMBIOS: Add code to build full smbios tables; build type 2 table
SMBIOS: Build full tables for types 0 and 1
SMBIOS: Remove unused code for passing individual fields to bios
SMBIOS: Build full type 3 table
SMBIOS: Build full type 4 tables
SMBIOS: Build full smbios memory tables (type 16, 17, 19, and 20)
SMBIOS: Build full tables for type 32 and 127
SMBIOS: Update all table definitions to smbios spec v2.3
SMBIOS: Remove SeaBIOS compatibility quirks
hw/i386/pc.c | 3 +
hw/i386/pc_piix.c | 15 +-
hw/i386/pc_q35.c | 11 +-
hw/i386/smbios.c | 758 +++++++++++++++++++++++++++++++++++++++++------
include/hw/i386/smbios.h | 47 ++-
5 files changed, 717 insertions(+), 117 deletions(-)
--
1.8.5.3
