Hi,
This does not satisfy the "should use QOM properties" requirement that we discussed in the RFC thread.
I don't know which part of the RFC thread still applied and which doesn't: at that point you were rejecting the whole approach.
I found a mail where you said: I'd be a lot happier if we were passing more information to this routine and not hard coding it. For instance, the PCI interrupt assignments, the APIC ids, the number of available CPUs, etc.
So this is exactly what this code does. What, exactly, would you like to see instead? Create a guest info QOM object, and encode all information used by ACPI generation as properties of this object?
Don't touch device code for this.
-void pvpanic_init(ISABus *bus) +void pvpanic_init(ISABus *bus, PcGuestInfo *guest_info) { ISADevice *dev;
- FWCfgState *fw_cfg = fw_cfg_find();
- FWCfgState *fw_cfg = guest_info->fw_cfg; if (!fw_cfg) { return; } dev = isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE);
- pvpanic_fw_cfg(dev, fw_cfg);
- pvpanic_guest_info(dev, guest_info);
}
To pick this one as example: Instead of patching pvpanic code to stuff config info into GuestInfo you should (1) search the device object tree for a pvpanic device and (b) if present read the ioport property to figure the base address.
/me suggests to check out qmp_qom_get() in qmp.c. Some qom aequivalent for qdev_find_recursive would be handy, dunno whenever such a thing exists already, Andreas?
I'd tend to accept GuestInfo as temporary thing for stuff which can't be figured using qom properties today. Anthony might disagree though.
cheers, Gerd