On 12/02/2016 11:06, Andrew Jones wrote:
> On Thu, Feb 11, 2016 at 06:47:22PM +0100, Laurent Vivier wrote:
>>
>>
>> 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.
>
> Thanks for the extra test. Just to be clear though, do you mean no
> errors are logged, but we still get the expected printf output? Or
> was nothing at all output (in which case we're badly broken)?
>
> If it's the former, then I guess I screwed up the rtas call somehow,
> most likely by the way I tried to prepare the rtas entry function
> pointer for jumping into the blob provided in the DT.
I have nothing at all. It hangs.
The command I run is:
kvm-unit-tests]$ sudo ./powerpc/run powerpc/selftest.elf -smp 2 -m 256
-append 'setup smp=2 mem=256'
qemu-system-ppc64 -machine pseries,accel=kvm -bios powerpc/boot_rom.bin
-display none -serial stdio -kernel powerpc/selftest.elf -smp 2 -m 256
-append setup smp=2 mem=256
^C
qemu: terminating on signal 2
The change I did:
--- a/lib/powerpc/io.c
+++ b/lib/powerpc/io.c
@@ -32,6 +32,6 @@ void exit(int code)
// FIXME: change this print-exit/rtas-poweroff to chr_testdev_exit()
// Maybe by plugging chr-testdev into a spapr-vty.
printf("\nEXIT: STATUS=%d\n", ((code) << 1) | 1);
- rtas_power_off();
+ //rtas_power_off();
halt(code);
}
Laurent
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
