From: Gerd Hoffmann <kraxel@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: agraf@suse.de, alex.williamson@redhat.com, seabios@seabios.org,
qemu-devel@nongnu.org, armbru@redhat.com,
"Gabriel L. Somlo" <gsomlo@gmail.com>,
imammedo@redhat.com, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Date: Wed, 02 Apr 2014 17:04:57 +0200 [thread overview]
Message-ID: <1396451097.31715.20.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <20140401202832.GA24065@morn.localdomain>
Hi,
> > From the conversation so far, it seems to me that:
> >
> > - type 0 is best left to the BIOS (user overrides via
> > command line at their own risk)
I think it was a bad idea to allow overriding type0 fields in the first
place. It also isn't used in practice. I don't think it is a big
problem to loose that capability.
> > - therefore, the maximum granularity of QEMU-generated
> > elements should be full tables of a given type, and
> > not the full SMBIOS blob at once (other mechanisms to
> > allow the BIOS to insert its own type 0 welcome, but
> > so far this seems the most straightforward one).
Just an idea: Is the table ordering important? I don't think so. If
qemu supplies a blob with all tables except type0, can the firmware
simply append a type0 record to the blob supplied by qemu?
> I don't agree - I think ultimately we want QEMU to generate the full
> SMBIOS table and pass it to the firmware via the romfile_loader
> mechanism.
I still think the firmware (and *only* the firmware) should supply the
type0 table. I also think seabios should fill in something more
sensible in there, such as "Vendor: SeaBIOS" and "Version:
rel-1.7.4-0-g96917a8-...".
> The only thing that has been raised as an issue with this
> is one bit in the smbios table (UEFI support).
IMO 'dmidecode -t0' should show what firmware you are running
(seabios/ovmf/coreboot/whatever), not something made up by qemu.
cheers,
Gerd
next prev parent reply other threads:[~2014-04-02 15:05 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 23:23 [Qemu-devel] [v4 PATCH 00/12] SMBIOS: build full tables in QEMU Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 01/12] SMBIOS: Rename smbios_set_type1_defaults() for more general use Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 02/12] SMBIOS: Use macro to set smbios defaults Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 03/12] SMBIOS: Use bitmaps to check for smbios table collisions Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 04/12] SMBIOS: Add code to build full smbios tables; build type 2 table Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 05/12] SMBIOS: Build full tables for types 0 and 1 Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 06/12] SMBIOS: Remove unused code for passing individual fields to bios Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 07/12] SMBIOS: Build full type 3 table Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 08/12] SMBIOS: Build full type 4 tables Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 09/12] SMBIOS: Build full smbios memory tables (type 16, 17, 19, and 20) Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 10/12] SMBIOS: Build full tables for type 32 and 127 Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 11/12] SMBIOS: Update all table definitions to smbios spec v2.3 Gabriel L. Somlo
2014-03-18 23:23 ` [Qemu-devel] [v4 PATCH 12/12] SMBIOS: Remove SeaBIOS compatibility quirks Gabriel L. Somlo
2014-03-26 19:58 ` [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU) Gabriel L. Somlo
2014-03-26 22:36 ` Kevin O'Connor
2014-03-31 20:18 ` Gabriel L. Somlo
2014-04-01 8:40 ` Laszlo Ersek
2014-04-01 14:39 ` Kevin O'Connor
2014-04-01 15:47 ` Laszlo Ersek
2014-04-01 18:47 ` Gabriel L. Somlo
2014-04-01 20:28 ` Kevin O'Connor
2014-04-01 21:28 ` Gabriel L. Somlo
2014-04-01 21:44 ` Laszlo Ersek
2014-04-01 22:00 ` Kevin O'Connor
2014-04-01 22:35 ` Laszlo Ersek
2014-04-02 12:38 ` Gabriel L. Somlo
2014-04-02 13:39 ` Laszlo Ersek
2014-04-05 2:48 ` Kevin O'Connor
2014-04-02 15:07 ` Gerd Hoffmann
2014-04-02 17:01 ` Gabriel L. Somlo
2014-04-03 1:57 ` Gabriel L. Somlo
2014-04-03 9:42 ` Laszlo Ersek
2014-04-03 13:32 ` Gabriel L. Somlo
2014-04-03 13:56 ` Laszlo Ersek
2014-04-07 6:50 ` Gerd Hoffmann
2014-04-07 6:47 ` Gerd Hoffmann
2014-04-01 21:48 ` Kevin O'Connor
2014-04-02 15:04 ` Gerd Hoffmann [this message]
2014-04-05 0:34 ` Kevin O'Connor
2014-04-05 1:15 ` Gabriel L. Somlo
2014-04-05 2:26 ` Kevin O'Connor
2014-04-07 7:09 ` Gerd Hoffmann
2014-04-07 14:14 ` Kevin O'Connor
2014-04-07 14:33 ` Laszlo Ersek
2014-04-07 14:49 ` Gabriel L. Somlo
2014-04-07 15:23 ` Kevin O'Connor
2014-04-07 18:05 ` Gabriel L. Somlo
2014-04-07 18:57 ` Kevin O'Connor
2014-04-08 13:51 ` Gabriel L. Somlo
2014-03-27 2:45 ` Gabriel L. Somlo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1396451097.31715.20.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=gsomlo@gmail.com \
--cc=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).