[SeaBIOS] KVM call agenda for 2013-06-11
Michael S. Tsirkin
mst at redhat.com
Tue Jun 11 21:15:24 CEST 2013
On Tue, Jun 11, 2013 at 08:06:15PM +0200, Laszlo Ersek wrote:
> On 06/11/13 17:45, Michael S. Tsirkin wrote:
>
> > To summarize, there's a concensus now that generating ACPI
> > tables in QEMU is a good idea.
> >
> > Two issues that need to be addressed:
> > - original patches break cross-version migration. Need to fix that.
> >
> > - Anthony requested that patchset is merged together with
> > some new feature. I'm not sure the reasoning is clear:
> > current a version intentionally generates tables
> > that are bug for bug compatible with seabios,
> > to simplify testing.
>
> Sorry about not following the series more closely -- is there now a qemu
> interface available that allows any firmware just take the tables, maybe
> to fix them up blindly / algorithmically, and to install them?
Yes.
> IOW, is the interface at such a point that in OVMF we could start
> looking throwing out specific code, in favor of implementing the generic
> fw-side algorithm?
>
> > It seems clear we have users for this such as
> > hotplug of devices behind pci bridges, so
> > why keep the infrastructure out of tree?
> >
> > Looking for something additional, smaller as the hotplug patch
> > is a bit big, so might delay merging.
> >
> >
> > Going forward - would we want to move
> > smbios as well? Everyone seems to think it's a
> > good idea.
>
> I think the current fw_cfg interface for SMBIOS tables is already good
> enough to save a lot of work in OVMF. Namely, if all required tables
> were generated (table template + field-wise patching) in qemu, and then
> all exported over fw_cfg as verbatim tables, my SMBIOS series currently
> pending for OVMF should be able to install them.
>
> This would save OVMF the coding of templates (and any necessary
> patching) for types 3, 4 (especially nasty), 9, 16, 17, 19, and 32.
> (Basically "all except type 0 and type 1", which are already implemented
> (but verbatim tables from qemu would take priority even for type 0 and
> type 1). Type 7 can be left out apparently; IIRC dmidecode doesn't
> report it even under SeaBIOS.)
>
> I'm not implying anyone should start working on this (myself included
> :)), but yeah, moving SMBIOS would save work in OVMF. (Provided there
> was any reason to support said SMBIOS tables in OVMF :))
>
> Thanks,
> Laszlo
More information about the SeaBIOS
mailing list