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
