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

[Gleb Natapov]

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.

> 
> It was also mentioned that this patch does not yet have to fix the
> cross-version migration issue with fw_cfg. If we agree on a direction,
> we will fix it then.
> 
> Lastly, a proposal was made by Michael to make the call bi-weekly
> instead of weekly, as we were cancelling it too much.
> There were no objections.
> 
> Thus, the next call is planned for June 11, 2013.
> 
> -- 
> MST
> 
> _______________________________________________
> SeaBIOS mailing list
> address@hidden
> http://www.seabios.org/mailman/listinfo/seabios

--
                        Gleb.