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