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

[Andreas Färber]

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

pc_i440fx_kvm.txt
Description: Text document

pc_q35_kvm.txt
Description: Text document

qom-tree
Description: Text document