On Tue, Jun 11, 2013 at 01:38:11PM -0500, Anthony Liguori wrote:
"Michael S. Tsirkin" mst@redhat.com 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.
So please look at it, that code has been posted. See: [PATCH] qemu: piix: PCI bridge ACPI hotplug support
it does not seem to show any major issues to work out besides the cross-version migration issue that we know about.
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.
But the user has been posted, even if there are still issues to work out with it, that should be enough to evaluate the infrastructure - the user itself does not need to be merged for this.
So please evaluate and give feedback.
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