Re: [PATCH v6 4/8] ppc/e500: Use start-powered-off CPUState property

[Thiago Jung Bauermann]

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 8/22/20 10:59 AM, Cédric Le Goater wrote:
>> Hello,
>> 
>> On 8/19/20 6:43 PM, Thiago Jung Bauermann wrote:
>>> Instead of setting CPUState::halted to 1 in ppce500_cpu_reset_sec(), use
>>> the start-powered-off property which makes cpu_common_reset() initialize it
>>> to 1 in common code.
>>>
>>> Also change creation of CPU object from cpu_create() to object_new() and
>>> qdev_realize_and_unref() because cpu_create() realizes the CPU and it's not
>>> possible to set a property after the object is realized.
>>>
>>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>> 
>> 
>> This is breaking make check : 
>> 
>>     tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 
>> 11 (Segmentation fault) (core dumped)
>>     ERROR boot-serial-test - too few tests run (expected 7, got 0)
>>     make: *** 
>> [/home/legoater/work/qemu/qemu-powernv-5.2.git/tests/Makefile.include:650: 
>> check-qtest-ppc64] Error 1
>>     make: *** Waiting for unfinished jobs....
>>     
>>     
>>     gdb --args build/ppc64-softmmu/qemu-system-ppc64  -display none   -M 
>> ppce500
>>     ...
>>     Thread 1 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
>>     0x000055555596ebf2 in ppce500_init (machine=0x5555567aa6e0)
>>         at /home/legoater/work/qemu/qemu-powernv-5.2.git/hw/ppc/e500.c:880
>>     880              irqs[i].irq[OPENPIC_OUTPUT_INT] = 
>> input[PPCE500_INPUT_INT];
>>  
>>     
>>     AFAIUI, 'input is not initialized since the CPU is not yet realized.
>
> Thiago, see ad938fc1d53 ("hw/arm/palm.c: Encapsulate misc GPIO handling
> in a device") and eventually f8a865d36dc ("hw/arm/allwinner-a10:
> Simplify by passing IRQs with qdev_pass_gpios") to get an idea how you
> can fix that.

I ended up not following this route. There were other patches in this
series which also caused problems in make check, but in those cases it
wasn't related to IRQ setup.

I started feeling like I had fallen into a rabbit hole so I opted
instead to solve these problems by minimizing the consequences of the
changes made by this patch series.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center