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