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