Add v2.3 fields to Type 17 (Memory Device) structure. Without these, selecting "About This Mac" on an OS X guest will crash and restart the GUI.
Signed-off-by: Gabriel Somlo somlo@cmu.edu --- src/fw/smbios.c | 6 ++++++ src/std/smbios.h | 6 ++++++ 2 files changed, 12 insertions(+)
diff --git a/src/fw/smbios.c b/src/fw/smbios.c index 55c662a..b2d7f14 100644 --- a/src/fw/smbios.c +++ b/src/fw/smbios.c @@ -417,6 +417,12 @@ smbios_init_type_17(void *start, u32 size_mb, int instance) set_field_with_default(17, memory_type, 0x07); /* RAM */ set_field_with_default(17, type_detail, 0);
+ set_field_with_default(17, speed, 0); /* unknown */ + load_str_field_or_skip(17, manufacturer_str); + load_str_field_or_skip(17, serial_number_str); + load_str_field_or_skip(17, asset_tag_number_str); + load_str_field_or_skip(17, part_number_str); + *end = 0; end++; if (!str_index) { diff --git a/src/std/smbios.h b/src/std/smbios.h index 0513716..ba0e95d 100644 --- a/src/std/smbios.h +++ b/src/std/smbios.h @@ -127,6 +127,12 @@ struct smbios_type_17 { u8 bank_locator_str; u8 memory_type; u16 type_detail; + /* v2.3 fields: */ + u16 speed; + u8 manufacturer_str; + u8 serial_number_str; + u8 asset_tag_number_str; + u8 part_number_str; } PACKED;
/* SMBIOS type 19 - Memory Array Mapped Address */
On Tue, Feb 04, 2014 at 02:02:59PM -0500, Gabriel L. Somlo wrote:
Add v2.3 fields to Type 17 (Memory Device) structure. Without these, selecting "About This Mac" on an OS X guest will crash and restart the GUI.
Thanks. In general, though, it is preferred to make smbios changes at the QEMU layer. Indeed, going forward, I'd like to see all the smbios stuff moved up to QEMU.
Is there something in these two patches that can't be done in QEMU?
-Kevin
On Wed, Feb 05, 2014 at 08:02:25PM -0500, Kevin O'Connor wrote:
On Tue, Feb 04, 2014 at 02:02:59PM -0500, Gabriel L. Somlo wrote:
Add v2.3 fields to Type 17 (Memory Device) structure. Without these, selecting "About This Mac" on an OS X guest will crash and restart the GUI.
Thanks. In general, though, it is preferred to make smbios changes at the QEMU layer. Indeed, going forward, I'd like to see all the smbios stuff moved up to QEMU.
Is there something in these two patches that can't be done in QEMU?
As far as I was able to tell by looking through QEMU's SMBIOS bits, right now it specifies some Type 1 defaults, and facilitates adding and/or overriding Type 0 and Type 1 options via the command line. It also allows loading a binary table (which can be obtained using dmidecode), but which appears to be partially merged with what's in SeaBIOS rather than completely replacing it. Maybe that's a bug, or maybe I'm missing something.
But anyhow, right now QEMU seems to be making relatively minor tweaks to something that's firmly at home in SeaBIOS, which is why I sent my patches to the latter...
If I'm wrong (which is very likely :) ), someone please set me straight.
Otherwise, would it make sense to accept the patches into SeaBIOS first, and if/when SMBIOS gets moved wholesale into QEMU at some later date, they can be part of that move (the way things happened with the ACPI tables a while back) ?
Thanks much, --Gabriel
Il 06/02/2014 14:38, Gabriel L. Somlo ha scritto:
But anyhow, right now QEMU seems to be making relatively minor tweaks to something that's firmly at home in SeaBIOS, which is why I sent my patches to the latter...
Yeah, that's correct. There's really no particular hook in QEMU to do this.
Paolo
-
Gabriel L. Somlo -
Kevin O'Connor -
Paolo Bonzini