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. -- 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
