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 > SeaBIOS@xxxxxxxxxxx > http://www.seabios.org/mailman/listinfo/seabios -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
