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

[Andrew Jones <drjones@redhat.com>]

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?

Thanks,
drew