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:
{ 'type': 'ObjectPropertyInfo', 'data': { 'name': 'str', 'type': 'str' } }
{ 'command': 'qom-list', 'data': { 'path': 'str' }, 'returns': [ 'ObjectPropertyInfo' ] }
{ 'command': 'qom-get', 'data': { 'path': 'str', 'property': 'str' }, 'returns': 'visitor', 'gen': 'no' }
I am proposing that we replace fw_cfg with a device that exports the QOM tree (read-only) via firmware.
We have a utility called qom-fuse that can mount a fuse filesystem that exports this as a proper filesystem too.
Here's a small example:
[06:26 PM] anthony🐵 titi:~/git/qemu/QMP/tmp$ find . ./machine ./machine/i440fx ./machine/i440fx/ioapic ./machine/i440fx/ioapic/parent_bus ./machine/i440fx/ioapic/realized ./machine/i440fx/ioapic/type ./machine/i440fx/pci.0 ./machine/i440fx/pci.0/child[5] ./machine/i440fx/pci.0/child[4] ./machine/i440fx/pci.0/child[3] ./machine/i440fx/pci.0/child[2] ./machine/i440fx/pci.0/child[1] ./machine/i440fx/pci.0/child[0] ...
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.
Presumably it would be good to expose the apic id too. This is already in the QOM tree.
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.
Regards,
Anthony Liguori
-Kevin