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.
drew
--
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
