On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote:
Kevin O'Connor kevin@koconnor.net writes:
On Mon, Jun 10, 2013 at 04:45:53PM -0500, Anthony Liguori wrote:
This discussion comes down to two things I think: (a) our existing firmware interface is pretty poor (b) we are duplicating work because of firmware licensing.
We can fix (a) and there's lots of value in doing that in terms of improving support for other architectures. We've discussed (b) in other threads and I've stated my opinion on the direction we need to take.
I'm not concerned about (b).
I'm quite curious how you are planning to solve (a). I think it would help move this conversation forward if you could take a couple acpi tables in use today (eg, madt, srat) and describe the future format and location for each field in those tables.
Sure. Today we expose the device model through a graph that can be losely mapped to a filesystem. We expose two methods of interest as part of our management api:
[...]
For the MADT table, right now SeaBIOS needs the CPU count. That can be found by counting the number of CPU nodes. Today cpus are unattached so they appear in /machine/unattached but we should put them in a /machine/cpu container for clarity.
SeaBIOS needs much more than the CPU count. The madt contains info on each interrupt - its global irq number, the legacy irq number, the acpi defined type of the irq, and the acpi defined flags for the irq. It also contains similar info on each cpu (including apic id), the io apic, and NMIs.
QOM is the full representation of the device state so we should not ever need to add additional things to fw_cfg. More likely than not, when SeaBIOS needs more information, it's already there so added functionality will probably Just Work with older QEMUs.
I think it would also be useful if you could do the same for a couple DSDT entries (eg, _SB.PCI0, _SB.PCI0.ISA) and also describe how you plan to have the guest build the AML from that info.
Likewise the slot count should be available too. We hard code slots today but it is something we should model properly. We would model it using QOM of course.
Internally within QEMU, this initial discussion started by saying that any ACPI generation within QEMU should happen strictly with QOM methods. This was the crux of my argument, if QOM is the only interface we need, everything is there for the firmware to do the same job that QEMU would be doing.
I think we keep talking past each other. You seem to be pointing out that the information seabios uses to patch its hardcoded tables can be passed in via QOM. Agreed, it can. I'm pointing out all the info that is hardcoded in seabios - I don't see how that can be passed via QOM.
All the hardcoded data in seabios is a problem, because when it changes (and it frequently does) it requires changes to both QEMU and SeaBIOS and those changes have to be coordinated. The key reason for moving the tables into QEMU is not that it can better patch the tables - the advantage is that it can hardcode the tables that need patching.
I can cite several recent examples of seabios change requests that require changing of the hardcoded tables: liguang wants to add an "embedded controller" hardware device which requires changes to seabios' dsdt, Corey Minyard wants to add IPMI hardware support (both smbios changes and DSDT changes), and Corey Bryant wants to add TPM hardware support.
How do we solve the problem of seabios having a ton of hardcoded information about the qemu hardware, and seabios having to change with the hardware modifications that qemu makes?
-Kevin