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

[Laszlo Ersek]

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?

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