On Thu, Mar 21, 2013 at 08:04:38PM -0400, Kevin O'Connor wrote:
On Thu, Mar 21, 2013 at 03:26:26PM +0200, Michael S. Tsirkin wrote:
On Thu, Mar 21, 2013 at 01:14:38PM +0000, David Woodhouse wrote:
On Thu, 2013-03-21 at 15:12 +0200, Michael S. Tsirkin wrote:
Anyway, I am not against such runtime flags.
If we add to this an option to build a minimal BIOS that only works with the new QEMU, do we have a deal?
Yeah, definitely. The code for SeaBIOS to build its own should certainly be optional. It should be possible to build a minimal SeaBIOS which *can't*.
Agreed.
Okay that's exactly what me and Laszlo are working on. We want to add a special way to build qemu and seabios such that they work with tables in qemu, then add runtime detection on top.
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?
-Kevin
Exactly, I'm proposing 1, on top of this, a set of compile-time flags to optionally stip unused tables from the bios binary.