Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

[Anthony Liguori <anthony@codemonkey.ws>]

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