qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]