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 _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
