Re: KVM call agenda for 2013-06-11

["Michael S. Tsirkin" <mst@redhat.com>]

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