From patchwork Fri Feb 12 10:31:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Vivier X-Patchwork-Id: 582139 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id A76AB140BCB for ; Fri, 12 Feb 2016 21:32:15 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751746AbcBLKbi (ORCPT ); Fri, 12 Feb 2016 05:31:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51173 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751463AbcBLKbh (ORCPT ); Fri, 12 Feb 2016 05:31:37 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 43A757AE87; Fri, 12 Feb 2016 10:31:37 +0000 (UTC) Received: from [10.36.112.18] (ovpn-112-18.ams2.redhat.com [10.36.112.18]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1CAVX1I008020; Fri, 12 Feb 2016 05:31:34 -0500 Subject: Re: [kvm-unit-tests PATCH v2 00/14] ppc64: initial drop To: Andrew Jones 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> 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 From: Laurent Vivier X-Enigmail-Draft-Status: N1110 Message-ID: <56BDB484.6020303@redhat.com> Date: Fri, 12 Feb 2016 11:31:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160212100633.whdxq6pnsdsfu2e2@hawk.localdomain> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org 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: Laurent --- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 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); }