On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote: > Gerd Hoffmann <kraxel@xxxxxxxxxx> writes: > > On 05/29/13 01:53, Kevin O'Connor wrote: > >> Raised > >> that QOM interface should be sufficient. > > > > Agree on this one. Ideally the acpi table generation code should be > > able to gather all information it needs from the qom tree, so it can be > > a standalone C file instead of being scattered over all qemu. > > Ack. So my basic argument is why not expose the QOM interfaces to > firmware and move the generation code there? I remain doubtful that QOM has all the info needed to generate the BIOS tables. Does QOM describe how the 5th pci device uses global interrupt 11 when using global interrupts, legacy interrupt 5 when not using global interrupts, and that the legacy interrupt can be changed by writing to the 0x60 address of the 1st pci device's config space? Does QOM state that the machine supports S3 sleep mode? Does QOM indicate that an IPMI device supports the 3rd version of the IPMI device specification? I don't see how exporting QOM to the firmware will help. I predict we would continue to see most of the BIOS tables hardcoded in the firmware and that all but the most minor changes to those tables would require synchronizing code patches to both QEMU and the firmware. I also suspect we would end up adding fields to QOM that only the BIOS tables cared about, and that ever increasing code would be needed in both QEMU and the firmware to juggle to/from QOM so that the BIOS tables could be created. -Kevin -- 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
