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

[Anthony Liguori]

"Michael S. Tsirkin" <address@hidden> writes:

> On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
>> Juan is not available now, and Anthony asked for
>> agenda to be sent early.
>> So here comes:
>> 
>> Agenda for the meeting Tue, June 11:
>>  
>> - Generating acpi tables, redux
>
> Not so much notes as a quick summary of the call:
>
> There are the following reasons to generate ACPI tables in QEMU:
>
> - sharing code with e.g. ovmf
>       Anthony thinks this is not a valid argument
>
> - so we can make tables more dynamic and move away from iasl
>       Anthony thinks this is not a valid reason too,
>       since qemu and seabios have access to same info
>       MST noted several info not accessible to bios.
>       Anthony said they can be added, e.g. by exposing
>       QOM to the bios.
>
> - even though most tables are static, hardcoded
>   they are likely to change over time
>       Anthony sees this as justified
>
> To summarize, there's a concensus now that generating ACPI
> tables in QEMU is a good idea.

I would say best worst idea ;-)

I am deeply concerned about the complexity it introduces but I don't see
many other options.

>
> 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.

I expect that there will be additional issues that need to be worked out
and want to see a feature that actually uses the infrastructure before
we add it.

>   It seems clear we have users for this such as
>   hotplug of devices behind pci bridges, so
>   why keep the infrastructure out of tree?

It's hard to evaluate the infrastructure without a user.

>   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.

Yes, independent of ACPI, I think QEMU should be generating the SMBIOS
tables.

Regards,

Anthony Liguori

> -- 
> MST