On Fri, Feb 12, 2016 at 11:31:32AM +0100, Laurent Vivier wrote:
>
>
> 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.
Damn. I'll need to get a machine where the problems reproduce to debug.
>
> 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);
> }
Yup, that's what I was hoping would make things "work", guess it doesn't.
Thanks for all the testing.
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
