[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call agenda for 2013-06-11
Date: Tue, 11 Jun 2013 13:38:11 -0500
User-agent: Notmuch/0.15.2+77~g661dcf8 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

"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


Anthony Liguori

> -- 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]