[SeaBIOS] [PATCH 2/2] accept MADT over fw_cfg

[Laszlo Ersek]

On 03/22/13 01:04, Kevin O'Connor wrote:
> On Thu, Mar 21, 2013 at 03:26:26PM +0200, Michael S. Tsirkin wrote:

>> The advantage is that we can make progress
>> without keeping lots of patches out of tree.
>> Unless of course Kevin nacks this all ...
> 
> I think we need to have a plan for what the final interface will look
> like.
> 
> Right now, we can't change QEMU to pass tables via the existing fw_cfg
> entries unless we upgrade SeaBIOS in QEMU first (otherwise things like
> duplicate MADT entries occur).  If we're going to upgrade SeaBIOS in
> QEMU, we really want that upgrade to be the final version.  We don't
> want to have to bump the seabios rev in qemu multiple times in
> lock-step with the changes.
> 
> So, I see two ways to do this:
> 
> 1 - update SeaBIOS with a patch series that makes it capable of
> handling all tables via existing and new fw_cfg entries (including
> flags to disable all internal tables), update QEMU to use that SeaBIOS
> rev, and then apply a patch series to QEMU that has it create all the
> tables (with the final patch flagging to seabios that it should no
> longer create any internal tables).
> 
> or, 2 - apply a patch series to QEMU that has it create all the tables
> via new fw_cfg entries, then apply a patch series to seabios that
> updates it to use the new fw_cfg entries instead of its existing
> internal tables, and then apply that new rev of seabios to qemu.
> 
> Were you proposing one of the above paths, or did you have something
> else in mind?

Both of these say "apply a patch series to QEMU that has it create all
the tables". I think it would be preferable (for whoever develops the
tables in qemu) to submit a standalone series per table, testable in
isolation. A huge series covering all tables would likely go up to v5+,
and waste a lot of developer & reviewer effort.

In
<http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5960/focus=6008>,

On 03/22/13 00:22, Kevin O'Connor wrote:

> In practice, one never wants to mix QEMU generated ACPI tables with
> SeaBIOS generated ACPI tables.

AIUI, this is exactly what we'd like to do during development.

But also in general I see no problem with this; *what* should be in any
given ACPI table is independent from the table's producer's identity.
(The producer only needs access to the dependencies, and that access is
producer-specific, like global variables or functions in qemu, fw_cfg in
SeaBIOS & OVMF).

The reason for the move is just that we don't want to duplicate work
between SeaBIOS and OVMF; a table being produced in qemu versus boot
firmware is not inherently right or wrong. (At least it wasn't
bothering/intriguing anyone until OVMF started to care about ACPI tables
in earnest).

Laszlo