[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [SeaBIOS] [PATCH 1/2] SMBIOS: Update Type 17 (Memory De
From: |
Gabriel L. Somlo |
Subject: |
Re: [Qemu-devel] [SeaBIOS] [PATCH 1/2] SMBIOS: Update Type 17 (Memory Device) struct to v2.3 |
Date: |
Thu, 6 Feb 2014 08:38:27 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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