On Tue, Jun 11, 2013 at 01:38:11PM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
