Re: [Qemu-devel] KVM call agenda for 2013-06-11

["Michael S. Tsirkin" <mst@redhat.com>]

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