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

[Kevin O'Connor <kevin@koconnor.net>]

On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann <kraxel@redhat.com> 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