[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU) |
Date: |
Tue, 01 Apr 2014 23:44:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
On 04/01/14 23:28, Gabriel L. Somlo wrote:
> On Tue, Apr 01, 2014 at 04:28:32PM -0400, Kevin O'Connor wrote:
>>> 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)
>>>
>>> - 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).
>>
>> 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. The only thing that has been raised as an issue with this
>> is one bit in the smbios table (UEFI support). For this one bit, I
>> think QEMU can just put together a sane default and the firmware can
>> patch up the one bit (either manually or via a new romfile_loader
>> command).
>>
>>>
>>> - this means the smbios structure header has to be left
>>> up to the BIOS
>>>
>>> - the BIOS is then responsible for setting the smbios
>>> spec version (2.4 for SeaBIOS, 2.7.1 for OVMF).
>>>
>>> On that last point, at least Linux seems to be OK with individual
>>> type tables having a higher version than the structure header; i.e.,
>>> dmidecode works fine when e.g. the structure header says 2.4 but
>>> the type 4 cpu record is 2.6. I'll test on Windows and OS X as well,
>>> and post my results here.
>>>
>>> My one remaining question is: how do we get the BIOS to *not* generate
>>> a certain table type that's being left out on purpose by QEMU ?
>>>
>>> I'm talking here of type 20, which is no longer required as of spec
>>> v2.5, and which would unnecessarily complicate things if/when more
>>> than two E820_RAM memory areas are present...
>>
>> The above are good examples why I think QEMU should be the sole owner
>> of the SMBIOS.
>
> Assuming all relevant QEMU maintainers are OK with the idea of
> creating a full SMBIOS blob (with e.g. type 0 defaulting to the
> relevant SeaBIOS values, override-able to fit some different bios,
> e.g. OVMF), would you take a patch to check for this blob in
> smbios_setup() (in SeaBIOS src/fw/smbios.c) ? Right now, it's either
> individual fields or table-at-a-time blobs only, AFAICT.
>
> Assuming "yes", would OVMF accept a similar patch (unless it's already
> set up to receive such a blob, I forget whether that came up earlier
> in the thread) ?
Right now, OVMF can accept individual fields, or table-at-a-time blobs,
via fw_cfg.
The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time
(for which table-at-a-time blobs are a perfect match).
If qemu gives OVMF a complete, concatenated dump of all tables, I'll
have to split that up into individual tables, and install those one by one.
qemu --[fw_cfg]--> OVMF platform code --[EFI_SMBIOS_PROTOCOL]--> edk2
"some" format: strictly per-table
- field patch
- per-table blob
- complete dump?
I think that concatenating table-at-a-time blobs in SeaBIOS is easier
than parsing & splitting a complete dump into tables in OVMF.
Kevin might disagree of course :)
Thanks
Laszlo
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU),
Laszlo Ersek <=
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/04
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gerd Hoffmann, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/03
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/03