Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

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

On Sun, Jun 02, 2013 at 06:40:43PM +0300, Gleb Natapov wrote:
> On Sun, Jun 02, 2013 at 06:09:50PM +0300, Michael S. Tsirkin wrote:
> > On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
> > > On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> > > > > On Thu, May 23, 2013 at 03:41:32PM +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, May 28:
> > > > > > 
> > > > > > - Generating acpi tables
> > > > > 
> > > > > I didn't see any meeting notes, but I thought it would be worthwhile
> > > > > to summarize the call.  This is from memory so correct me if I got
> > > > > anything wrong.
> > > > > 
> > > > > Anthony believes that the generation of ACPI tables is the task of the
> > > > > firmware.  Reasons cited include security implications of running more
> > > > > code in qemu vs the guest context, complexities in running iasl on
> > > > > big-endian machines, possible complexity of having to regenerate
> > > > > tables on a vm reboot, overall sloppiness of doing it in QEMU.  Raised
> > > > > that QOM interface should be sufficient.
> > > > > 
> > > > > Kevin believes that the bios table code should be moved up into QEMU.
> > > > > Reasons cited include the churn rate in SeaBIOS for this QEMU feature
> > > > > (15-20% of all SeaBIOS commits since integrating with QEMU have been
> > > > > for bios tables; 20% of SeaBIOS commits in last year), complexity of
> > > > > trying to pass all the content needed to generate the tables (eg,
> > > > > device details, power tree, irq routing), complexity of scheduling
> > > > > changes across different repos and synchronizing their rollout,
> > > > > complexity of implemeting the code in both OVMF and SeaBIOS.  Kevin
> > > > > wasn't aware of a requirement to regenerate acpi tables on a vm
> > > > > reboot.
> > > > 
> > > > I think this last one is based on a misunderstanding: it's based
> > > > on assumption that we we change hardware by hotplug
> > > > we should regenerate the tables to match.
> > > > But there's no management that can take advantage of
> > > > this.
> > > > Two possible reasonable things we can tell management:
> > > > - hotplug for device XXX is not supported: restart qemu
> > > >   to make guest use the device
> > > > - hotplug for device XXX is supported
> > > > 
> > > > What is proposed here instead is a third option:
> > > > - hotplug is supported but device is not functional.
> > > >   reboot guest to make it fully functional
> > > > 
> > > > This will naturally lead to requirement to regenerate tables on reset.
> > > > 
> > > > And this is what would happen with guest-generated
> > > > tables, and I consider this a bug, not a feature.
> > > > 
> > > +1. This will probably break guest resume too.
> > > 
> > > > If you really wanted to update tables dynamically, without restarting
> > > > qemu, don't stop there, add an interface for guest to update them
> > > > without reset. I think that's over-endineering and a
> > > > requirement that's best avoided.
> > > > 
> > > > 
> > > > > There were discussions on potentially introducing a middle component
> > > > > to generate the tables.  Coreboot was raised as a possibility, and
> > > > > David thought it would be okay to use coreboot for both OVMF and
> > > > > SeaBIOS.  The possibility was also raised of a "rom" that lives in the
> > > > > qemu repo, is run in the guest, and generates the tables (which is
> > > > > similar to the hvmloader approach that Xen uses).
> > > > > 
> > > > > Anthony requested that patches be made that generate the ACPI tables
> > > > > in QEMU for the upcoming hotplug work, so that they could be evaluated
> > > > > to see if they truly do need to live in QEMU or if the code could live
> > > > > in the firmware.  There were no objections.
> > > > > 
> > > > > -Kevin
> > > > 
> > > > I volunteered to implement this.
> > > Why hotplug should generate ACPI code? It does not do so on real HW.
> > 
> > Hotplug should not generate ACPI code.
> > What is meant here is adding ACPI code to support hotplug
> > of devices behind a PCI to PCI bridge.
> > 
> Ah, OK. This one does not change on reset.

It wouldn't if QEMU generates it.
With bios generating the tables it might depending
on how it's implemented.
To make it not change across resets we'd need
an interface in QEMU to tell guest whether a
device was added since QEMU start.

> --
> 			Gleb.