Re: [kvm-unit-tests PATCH v2 00/14] ppc64: initial drop

[Laurent Vivier <lvivier@redhat.com>]

On 11/02/2016 18:22, Andrew Jones wrote:
> On Thu, Feb 11, 2016 at 05:44:00PM +0100, Laurent Vivier wrote:
>>
>>
>> On 11/02/2016 16:29, Andrew Jones wrote:
>>> On Thu, Feb 11, 2016 at 02:36:57PM +0100, Laurent Vivier wrote:
>>
>>>>
>>>> - On fedora 23 on PowerMac G5 (ppc64) kvm_pr, it doesn't work at all:
>>>>
>>>> lib/powerpc/setup.c:60: assert failed
>>>>  59         assert(freemem_start >= mem_start && freemem_start < mem_end);
>>>>
>>>> The values I have are:
>>>> freemem_start 434000 mem_start 8000000 mem_end 10000000
>>>
>>> That's interesting. I might know what the problem is though. If
>>> the spapr machine divides memory up into multiple regions in some
>>> kvm use cases, then I'll need to look at all of regions to either a)
>>> choose the one I want to use, or b) map them all for use. On that
>>> machine, can you run
>>>
>>> $ /usr/libexec/qemu-kvm -machine pseries,accel=kvm -machine dumpdtb=dtb
>>> $ dtc -I dtb -O dts dtb | less
>>>
>>> and then check if there are multiple memory regions?
>>
>> No output... fc23 has qemu-2.4.1, so this commit is missing:
>> ad440b4 spapr: add dumpdtb support
>>
>> So I've recompiled master (PPC970MP is not as fast as POWER8...), and:
>>
>>         memory@0000000010000000 {
>>                 ibm,associativity = <0x4 0x0 0x0 0x0 0x0>;
>>                 reg = <0x0 0x10000000 0x0 0x10000000>;
>>                 device_type = "memory";
>>         };
>>
>>         memory@0000000008000000 {
>>                 ibm,associativity = <0x4 0x0 0x0 0x0 0x0>;
>>                 reg = <0x0 0x8000000 0x0 0x8000000>;
>>                 device_type = "memory";
>>         };
>>
>>         memory@0000000000000000 {
>>                 ibm,associativity = <0x4 0x0 0x0 0x0 0x0>;
>>                 reg = <0x0 0x0 0x0 0x8000000>;
>>                 device_type = "memory";
>>         };
> 
> OK, I can fix memory region mapping for v3 pretty easily.
> 
>>
>> But master doesn't have the "assert()", it hangs, and in kernel logs:
>>
>> [  438.503410] kvmppc_handle_exit_pr: emulation at 700 failed (00000000)
>> [  438.503412] Couldn't emulate instruction 0x00000000 (op 0 xop 0)
> 
> That 700 is what I got when I tried compiling with gcc-5.2, before
> changing the toc alignment. I guess that just means "we've gone off
> in the weeds." Unfortunately I don't have any idea why this time,
> assuming we've got the toc patched kvm-unit-tests. Does everything
> run except the rtas-poweroff command? If you comment the call to it
> out of exit(), and then just use ^C to quit, does it seem happy?

Yes, it seems happy: nothing is displayed in terminal nor in the kernel
logs.

Laurent