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

[Gleb Natapov]

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.

--
                        Gleb.