[SeaBIOS] KVM call agenda for 2013-06-11
Michael S. Tsirkin
mst at redhat.com
Tue Jun 11 21:22:52 CEST 2013
On Tue, Jun 11, 2013 at 01:38:11PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst at 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
More information about the SeaBIOS
mailing list