qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/6] xics: split to xics and xics-common


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [PATCH 5/6] xics: split to xics and xics-common
Date: Thu, 08 Aug 2013 13:10:03 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

On 08/08/2013 12:22 AM, Andreas Färber wrote:
> Am 07.08.2013 09:26, schrieb Alexey Kardashevskiy:
>> On 08/07/2013 05:03 PM, Andreas Färber wrote:
>>> Am 07.08.2013 08:06, schrieb Alexey Kardashevskiy:
>>>> [...] How do I test it?
>>>
>>> ./QMP/qom-list to find the path, if not fixed in code yet, and
>>
>> Something is wrong. XICS does not have an id but it should not be a
>> problem, right (btw how to set it from the code?)?
>>
>> address@hidden ~]$ ./qemu-impreza/QMP/qom-list -s ./qmp-sock
>> /
> 
> That's expected for lack of argument.
> 
> $ ./QMP/qom-list -s ./qmp-sock /machine
> unattached/
> peripheral/
> peripheral-anon/
> type
> 
> This confirms "path ... not fixed in code yet" (otherwise there would've
> been an "spapr/" entry or anything else telling.
> 
> So you need to look through /machine/unassigned for the device[n] with
> qom-get /machine/unassigned/device[n].type matching your type, possibly
> device[0] as in my case. From there on you see your icp[0]/ and ics/
> children without searching the unassigned list again.
> 
> Or simply use my qom-tree script:
> http://lists.nongnu.org/archive/html/qemu-devel/2013-07/txte1WIbWzu5Z.txt

Yep. That works, thanks.

> Setting a canonical path is done via object_property_add_child() after
> instantiating and before realizing a device.
> For x86 the northbridge is used as name, i.e. "i440fx" for pc and "q35"
> for q35. Suggest to discuss with Anthony how to structure the
> composition tree for sPAPR.

I tried inserting this:
object_property_add_child(qdev_get_machine(), busname, OBJECT(dev), NULL);

in TYPE_SPAPR_PCI_HOST_BRIDGE's spapr_phb_init() (I thought this is what
i440fx_init() does in the very beginning) but when I do that, spapr_phb
already has a parent of a "container" type so assert happens.

What is the aim of all of this? Is it not to have "unattached" in a path
starting with /machine?


btw I have added notes in the previous response against splitting ICS
initialization into 2 functions and you skipped it. Does this mean you do
not want to waste more of your time persuading me and this is the real
stopped or you just gave up? :) Thanks.


-- 
Alexey



reply via email to

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