[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/5] machine: introduce get_fw_dev_pa

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/5] machine: introduce get_fw_dev_path() callback
Date: Wed, 11 Dec 2013 16:20:34 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

On 12/04/2013 01:58 AM, Paolo Bonzini wrote:
> Il 03/12/2013 15:35, Andreas Färber ha scritto:
>> Am 03.12.2013 15:00, schrieb Paolo Bonzini:
>>> Il 03/12/2013 14:44, Andreas Färber ha scritto:
>>>>>> You can check "if (current_machine &&
>>>>>> current_machine->get_fw_dev_path)", and move current_machine from vl.c
>>>>>> to hw/qdev/core.c.
>>>> Please don't encourage moving random stuff into "core" device code.
>>>> If needed, we can easily add a machine.c, but that should remain
>>>> softmmu-only.
>>> Another solution would be to:
>>> (1) add an interface which contains "get_fw_dev_path".  When
>>> qdev_get_fw_dev_path is called, walk the QOM tree until an object that
>>> implements the interface is found.  If none is found, call the bus
>>> implementation as usual.
>>> (2) in vl.c, add a way for current_machine to override the /machine
>>> object.  A 100%-QOMified machine indeed could put a SOC-like Device there.
>>> (3) for spapr, define the machine object to something that implements
>>> said interface.
>>> It seemed a bit complicated for this particular problem, but I cannot
>>> say it's overengineered.
>>> More aspects of the configuration could be moved to the new interface
>>> over time, for example compat properties.
>> I remember Hervé running into problems with interfaces and ppc -cpu ?
>> (or -cpu host?), which does an object_class_foreach(), in the middle of
>> which QOM interfaces tried registering new types, leading to a GLib
>> assertion. Anthony never replied to that patch despite repeated pings,
>> so the issue is likely still unresolved.
>> http://patchwork.ozlabs.org/patch/241072/ (proposed workaround)
>> http://patchwork.ozlabs.org/patch/241504/ (test case)
>> http://patchwork.ozlabs.org/patch/241073/ (actual interface attempt)
> Well, let's fix it.  Thanks for the test case.

Any progress on this?

I am asking since the patchset about bootindex you gave me yesterday prints
"(process:38896): GLib-CRITICAL **: g_hash_table_foreach: assertion
`version == hash_table->version' failed" which I "fixed" by moving the
machine object creation chunk before kvm_init() in vl.c.

btw what do I do with that patchset now? I works for me (except the issue
above), do I have to repost it again? Thanks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]