From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E36F9C07E9B for ; Tue, 20 Jul 2021 14:04:08 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5AC596113C for ; Tue, 20 Jul 2021 14:04:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5AC596113C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=eik.bme.hu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5qLv-0003DZ-59 for qemu-devel@archiver.kernel.org; Tue, 20 Jul 2021 10:04:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5qKp-0002Nu-Sz; Tue, 20 Jul 2021 10:02:59 -0400 Received: from zero.eik.bme.hu ([2001:738:2001:2001::2001]:60800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5qKh-00032W-RK; Tue, 20 Jul 2021 10:02:58 -0400 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id AD31D74570C; Tue, 20 Jul 2021 16:02:43 +0200 (CEST) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 70DB8745708; Tue, 20 Jul 2021 16:02:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 6DE3774570B; Tue, 20 Jul 2021 16:02:43 +0200 (CEST) Date: Tue, 20 Jul 2021 16:02:43 +0200 (CEST) From: BALATON Zoltan To: luigi burdo Subject: Re: R: R: [PULL 0/3] ppc-for-6.1 queue 20210713 In-Reply-To: Message-ID: <36811435-c01f-ab84-9525-2a4cfa282ace@eik.bme.hu> References: <20210713020736.28960-1-david@gibson.dropbear.id.au> , MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: pass client-ip=2001:738:2001:2001::2001; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hello, On Tue, 20 Jul 2021, luigi burdo wrote: > i was able to build on my quad qemu, a ram bank was die and make me the issue with gcc.. > this is what happening if i run pegasos 2 with --enable-kvm. OK. Can you also show the full command so we know what options you used? > via_superio_cfg: unimplemented register 0xf2 > via_superio_cfg: unimplemented register 0xf4 > via_superio_cfg: unimplemented register 0xf6 > via_superio_cfg: unimplemented register 0xf7 > via_superio_cfg: unimplemented register 0xf4 > via_superio_cfg: unimplemented register 0xf2 > PegasosII Boot Strap (c) 2002-2003 bplan GmbH > Running on CPU PVR:000C0209 > Enable L1 ICache... Done. > mv64361_write: Unimplemented register write 0x108 = 0 > Reading W83194 : FAILED. > Setting Front Side Bus to 133MHz... FAILED. > Invalid access at addr 0xFE000E43, size 1, region '(null)', reason: rejected So this shows that what I've seen on emulated KVM (running QEMU in a PPC Linux guest running on qemu-system-ppc64 -M mac99) does not match what real hardware does so that could be a bug in emulated KVM. As shown at the end of this message: https://lists.nongnu.org/archive/html/qemu-ppc/2021-06/msg00146.html I did not get the Invalid access warning but instead got endless kvm exits with the NIP not incrementing past the instruction doing this invalid access so probably there's a problem with handling invalid access with emulated KVM PR but I don't know where to look for that problem or how to fix it. It could also be a bug in guest kernel or QEMU, I'm not sure. Hope somebody with more knowledge about PPC KVM could give some hints. Aparently this is not a problem on real machine where it works as expected (the Invalid address is because we don't emulate this device but it's not needed and it boots without it and we get the same warnings with TCG). > Invalid access at addr 0xFE000E44, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE000E41, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE000E42, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE000E40, size 1, region '(null)', reason: rejected > Configuring DDR...mv64361_write: Unimplemented register write 0x1494 = 291 [...] > Releasing IDE reset ... Done. > Configuring Legacy Devices > Initializing KBD...Invalid access at addr 0xFE0003F0, size 1, region '(null)', reason: rejected > Done. > via_superio_cfg: unimplemented register 0xf6 > via_superio_cfg: unimplemented register 0xf7 > via_superio_cfg: unimplemented register 0xf2 > Invalid access at addr 0xFE000084, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE000085, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE000086, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE000088, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE00008C, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE00008D, size 1, region '(null)', reason: rejected > Invalid access at addr 0xFE00008E, size 1, region '(null)', reason: rejected > Testing 10000000 Bytes, Pass: 00000000 Failed: 00000000 So does it stop here or do you get to the firmware ok prompt? > In dmesg i had many of this. > > [ 3634.418495] kvmppc_exit_pr_progint: emulation at 700 failed (00000700) > [ 3634.418525] Couldn't emulate instruction 0x00000700 (op 0 xop 896) > [ 3634.418551] Couldn't emulate instruction 0x00000700 (op 0 xop 896) > [ 3634.418577] Couldn't emulate instruction 0x00000700 (op 0 xop 896) > [ 3634.418603] Couldn't emulate instr... This looks like we're getting Program Exceptions that's raised for invalid instructions so either it's going off track and tries to execute something it should not or could be that since we're running G4 code on a G5 there may be some differences so an instruction valid on G4 could be invalid on G5? KVM should handle these but not sure it does for all such cases or it works correctly as this was probably not tested for a while. We would need to know where it got the exception but the above logs don't show that. Was there anything before these? Maybe there's a kvm trace you can enable or adding -d int would show the exception but that would generate a lot of logs so you may need to filter out some unneeded ones to find the relevant logs. We'd need the address where it got the exception that make it go to 0x700 and the opcode at that address. The logs above only show that it got to 0x700 and got endless exceptions where as a handler for Program Exception should be at 0x700 but probably the firmware did not install one as it should not get such exceptions when working normally on a G4. Which firmware version are you using? The 1.1 from up050404 should work but the 1.2 from MorphOS storage is known to have a cmpd instruction that's invalid on G4 yet it works but may raise an exception or do something else on G5. With TCG that's fixed by this patch: https://lists.nongnu.org/archive/html/qemu-ppc/2021-07/msg00207.html that's not in master yet but if using that firmware version this may also cause problem in KVM if it does not do the same on G5 than on G4. I don't know if that's the case but it's a possibility. Once we find out what opcode is causing the program exception we can look up in the G5 and G4 manuals to see why it gets the exception and what can we do about it. > i will build latest linux kernel and do new test. Apart from that you could also try what happens with the sc 1 calls that is used but VOF when you use -kernel boot.img instead of -bios pegasos2.rom. I got the host QEMU crash with that when trying on emulated KVM but if it works on real hardware that could also be fixed in emulation so I can at least reproduce the problems you find on real hardware. Regards, BALATON Zoltan