Re: [Qemu-devel] [PATCH v3 00/14] qemu: generate acpi tables for the guest

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Jul 28, 2013 at 01:22:57AM +0200, Andreas Färber wrote:
> Am 26.07.2013 14:19, schrieb Andreas Färber:
> > Am 25.07.2013 18:19, schrieb Michael S. Tsirkin:
> >> On Thu, Jul 25, 2013 at 05:50:55PM +0200, Andreas Färber wrote:
> >>> Am 24.07.2013 18:01, schrieb Michael S. Tsirkin:
> >>>> This code can also be found here:
> >>>> git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi
> >>>>
> >>>> Please review, and consider for 1.6.
> >>>
> >>> Quite frankly, this is still not looking the way I imagined it based on
> >>> the KVM call discussion and Anthony's comments that I remember:
> >>>
> >>> I believe Anthony asked to extract the information from the QOM tree,
> >>> originally from the SeaBIOS side, then later agreeing to do it on the
> >>> QEMU side.
> >>>
> >>> However here I am still seeing *functions* added in device code to check
> >>> device existence and to extract individual fields. I was assuming (and
> >>> clearly prefer) such code to live in a central place, be it acpi-build.c
> >>> or something else, and to use QOM *API*s to obtain information when
> >>> needed rather than building up lots of new structs duplicating that
> >>> data. That would at the same time be a test case for how useful the QOM
> >>> tree is
> >>>
> >>> I'm not sure if there was a misunderstanding or whether the PC QOM model
> >>> still sucks^W is incomplete? Anthony and Ping Fang(?) had both posted
> >>> patches to improve the composition tree once. If there's properties
> >>> missing that you need to access for ACPI, we should simply add them.
> >>> For i440fx we have /machine/i440fx.
> >>> For q35 I encountered an mch child on q35-pcihost, but what's trivially
> >>> missing apparently is to add q35-pcihost as a child to /machine, e.g.
> >>> /machine/q35.
> >>> Then you'll end up doing
> >>> Object *obj = object_resolve_path_component(qdev_get_machine(), "q35/mch");
> >>> object_property_get_int(obj, "foo", &err);
> >>> object_property_get_string(obj, "bar", &err);
> >>> and so on. No need to do the TYPE_... based search for everything.
> >>>
> >>> User-added -devices will show up in /machine/peripheral or
> >>> /machine/peripheral-anon depending on whether id= is used, so there a
> >>> type-based search probably makes sense. And there is nothing wrong with
> >>> moving the TYPE_* constants to a device header where not yet the case,
> >>> to allow that from generic code.
> >>>
> >>> Similarly, please don't open-code OBJECT_CHECK()s, do a trivial patch
> >>> with a macro that we can then reuse elsewhere. I'd be happy to review
> >>> such QOM patches and help fast-track them into master.
> >>>
> >>> Will take a closer look at the implementation later.
> >>
> >> This is not my understanding of previous comments on list
> >> or on KVM call.
> >>
> >> Basically it sounds like you want to make my work depend on completion
> >> of QOM conversion.
> >> I think we explicitly agreed full QOM convertion is not a blocker.
> > 
> > Not sure what you mean with "completion of QOM conversion" or "full QOM
> > conversion". What I am saying is that instead of spending time adding
> > functions to devices that fulfill your own ACPI needs only, that time
> > were better spent adding QOM properties where not yet existent.
> > 
> > Because then what you can access for ACPI can also be accessed by
> > libvirt and other management tools as well as qtest - I consider it a
> > test case. QMP does not offer an instance/path search by type.
> 
> To clarify for everyone what we're talking about here, I'm attaching
> /machine composition tree dumps for pc,accel=kvm and q35,accel=kvm plus
> the rudimentary script I used to generate it.
> 
> It shows for instance the mentioned /machine/i440fx and lack of
> /machine/q35. It also shows that there would be a /machine/fw_cfg.
> 
> Paths starting with /machine/unassigned shouldn't be hardcoded anywhere
> (that's the nobody-added-it-as-a-child<> bucket), except maybe for
> /machine/unassigned/sysbus. But whenever there's a link from a named
> device to a /machine/unassigned/device[n] that may of course be used
> dynamically, e.g. /machine/icc-bridge/icc to discover CPUs and APICs.
> 
> HTH,
> Andreas

So q35 is all "unassigned".
I assume it's fine to use APIs for that, then?

-- 
MST