Re: [Qemu-devel] [PATCH v2 3/5] acpi: pc: add fw_cfg device node to ssdt

[Eduardo Habkost]

On Mon, Sep 14, 2015 at 04:54:25PM -0400, Gabriel L. Somlo wrote:
> On Mon, Sep 14, 2015 at 04:34:02PM -0400, Gabriel L. Somlo wrote:
> > > > So I'll replace the "if (guest_info->fw_cfg)" check with
> > > > "if machine-type >= (pc-q35-2.5 or pc-i440fx-2.5))", in v3,
> > > > as soon as the patches for the 2.5 machine type make it into
> > > > git master (I remember seeing a reviewed-by fly by for that
> > > > earlier today :)
> > > 
> > > Sounds good, assuming you are going to implement the "machine-type >= 
> > > pc-2.5"
> > > check with something like: 
> > > PC_MACHINE_GET_CLASS(machine)->acpi_no_fw_cfg_node.
> > 
> > Thanks, that gives me something to grep for ;)
> > 
> > I was going to mimic how other acpi related decisions are made on pc
> > (piix or q35), something like below. Might even be the same thing,
> > once I learn about PC_MACHINE_GET_CLASS :)
> 
> OK, so not exactly the same thing. What's the trade-off between
> adding a boolean field to PCMachineClass vs. PcGuestInfo? Either
> would work technically, and PcGuestInfo already has a bunch of
> acpi related booleans. But if the new canonical place for this
> kind of thing is PCMachineClass rather than PcGuestInfo, it's OK
> with me...

PCGuestInfo is initialized only when pc_init1() is called and we are
already initializing a machine. PCMachineClass is initialized when the
corresponding machine_options() is called at class_init time. Keeping
machine-specific compat info at PCMachineClass will allow us to move
that information somewhere else more easily in the future (and allow us
to avoid needing new global variables and new pc_compat_*() functions).

See how PCMachineClass::broken_reserved_end gets used, for reference.

-- 
Eduardo