[SeaBIOS] [PATCH 2/2] accept MADT over fw_cfg
lersek at redhat.com
Thu Mar 21 13:56:02 CET 2013
On 03/21/13 13:23, David Woodhouse wrote:
> On Wed, 2013-03-20 at 20:22 -0400, Kevin O'Connor wrote:
>> On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
>>> Signed-off-by: Laszlo Ersek <lersek at redhat.com>
>> I think we need to figure out what the final fw_cfg interface for
>> ACPI, SMBIOS, mptable, and PIR will be.
> Once we have consensus, we can implement this on the OVMF side too. Is
> anyone (Laszlo?) looking at that, or should I?
I figured we should design and implement the thing first between qemu
and seabios (seabios being the more widely used firmware ATM I reckon),
soak it in user testing, and then implement a "ready plan" in OVMF. I
expect a lot of back&forth in this, so let's not double it :)
As long as qemu is exporting the current fw_cfg keys, present code in
OVMF shouldn't break even if we export some more stuff.
>> For SMBIOS, I don't think we should use the existing fw_cfg mechanism.
>> It's too complicated for what is needed. Instead, one fw_cfg "file"
>> entry with the whole smbios table should suffice.
> Agreed. I'd already looked at doing this in OVMF, and run away
In light of this, your offer above is even more appreciated :)
I wouldn't mind doing the OVMF side from an emotional standpoint, I just
feel overloaded / overwhelmed already by what I'm looking at. So
certainly don't wait for me (but consider that only work that is not
done is not lost). If you pick it up I'm thankful, if you don't, I can
still tack it to my todo list.
>> For mptable and PIR, there is no current mechanism, so we can add new
>> fw_cfg "files" for them. However, for all of these SeaBIOS needs to
>> be able to determine when it needs to create the table and when no
>> table should be published at all.
> I'd make it all-or-nothing. Except for a few historical qemu commits if
> you're bisecting, why would qemu ever provide a *partial* set of tables?
I can visualize myself implementing Michael's build time option
suggestion: if the option is set, SeaBIOS installs its own MADT (and any
MADT from qemu will create a duplicate); if the option is clear, SeaBIOS
won't install its own MADT (and if qemu doesn't provide one either, no
MADT will be present). So,
- for an earlier qemu, the option must be set,
- for a later qemu the option must be clear &&
(no -acpitable switch must be specified on the qemu cmldine ||
one -acpitable switch must load a MADT)
More information about the SeaBIOS