From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jones Subject: Re: [kvm-unit-tests PATCH v2 00/14] ppc64: initial drop Date: Fri, 12 Feb 2016 11:57:51 +0100 Message-ID: <20160212105751.kwc5v6ogijncntwv@hawk.localdomain> References: <1454957594-30601-1-git-send-email-drjones@redhat.com> <56BC8E79.7050409@redhat.com> <20160211152951.ydfr5xqpcbkzu27y@hawk.localdomain> <56BCBA50.6080900@redhat.com> <20160211172210.xcwrvz3dfp7kdnzi@hawk.localdomain> <56BCC92A.4060108@redhat.com> <20160212100633.whdxq6pnsdsfu2e2@hawk.localdomain> <56BDB484.6020303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, thuth@redhat.com, dgibson@redhat.com, david@gibson.dropbear.id.au, agraf@suse.de, pbonzini@redhat.com To: Laurent Vivier Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35065 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751576AbcBLK55 (ORCPT ); Fri, 12 Feb 2016 05:57:57 -0500 Content-Disposition: inline In-Reply-To: <56BDB484.6020303@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jones Date: Fri, 12 Feb 2016 10:57:51 +0000 Subject: Re: [kvm-unit-tests PATCH v2 00/14] ppc64: initial drop Message-Id: <20160212105751.kwc5v6ogijncntwv@hawk.localdomain> List-Id: References: <1454957594-30601-1-git-send-email-drjones@redhat.com> <56BC8E79.7050409@redhat.com> <20160211152951.ydfr5xqpcbkzu27y@hawk.localdomain> <56BCBA50.6080900@redhat.com> <20160211172210.xcwrvz3dfp7kdnzi@hawk.localdomain> <56BCC92A.4060108@redhat.com> <20160212100633.whdxq6pnsdsfu2e2@hawk.localdomain> <56BDB484.6020303@redhat.com> In-Reply-To: <56BDB484.6020303@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Laurent Vivier Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, thuth@redhat.com, dgibson@redhat.com, david@gibson.dropbear.id.au, agraf@suse.de, pbonzini@redhat.com 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%6' > 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%6 > ^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