From patchwork Sun Mar 4 13:38:45 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 144512 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 8FF62B6FA3 for ; Mon, 5 Mar 2012 00:39:01 +1100 (EST) Received: from localhost ([::1]:33528 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4BeJ-0008Er-Cy for incoming@patchwork.ozlabs.org; Sun, 04 Mar 2012 08:38:55 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4BeC-0008Ej-L3 for qemu-devel@nongnu.org; Sun, 04 Mar 2012 08:38:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4BeA-0000UH-9A for qemu-devel@nongnu.org; Sun, 04 Mar 2012 08:38:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4BeA-0000Rr-1M for qemu-devel@nongnu.org; Sun, 04 Mar 2012 08:38:46 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q24DcbPD001279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Mar 2012 08:38:37 -0500 Received: from redhat.com (vpn-200-101.tlv.redhat.com [10.35.200.101]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q24DcYIS025727; Sun, 4 Mar 2012 08:38:34 -0500 Date: Sun, 4 Mar 2012 15:38:45 +0200 From: "Michael S. Tsirkin" To: Blue Swirl Message-ID: <20120304133845.GA12298@redhat.com> References: <20120304094614.GA8158@redhat.com> <20120304122100.GA11207@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id q24DcbPD001279 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Cc: Mark Cave-Ayland , qemu-devel@nongnu.org, Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin wrote: > > On Sun, Mar 04, 2012 at 10:27:24AM +0000, Blue Swirl wrote: > >> On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin wrote: > >> > commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced > >> > a regression: we do not make IO base/limit upper 16 > >> > bit registers writeable, so we should report a 16 bit > >> > IO range type, not a 32 bit one. > >> > Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. > >> > > >> > In particular, this broke sparc64. > >> > > >> > Note: this just reverts to behaviour prior to the patch. > >> > Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 > >> > registers writeable should, and seems to, work just as well, but > >> > as no system seems to actually be interested in 32 bit IO, > >> > let's not make unnecessary changes. > >> > > >> > Reported-by: Mark Cave-Ayland > >> > Signed-off-by: Michael S. Tsirkin > >> > > >> > Mark, can you confirm that this fixes the bug for you? > >> > >> No, running > >> qemu-system-sparc64 -serial stdio > >> still shows black screen and the following on console: > >> OpenBIOS for Sparc64 > >> Unhandled Exception 0x0000000000000032 > >> PC = 0x00000000ffd19e18 NPC = 0x00000000ffd19e1c > >> Stopping execution > > > > The weird thing is the range type does not seem to be accessed > > at all. So I guessed there's some memory corruption here. > > Running valgrind shows this: > > > > --11114-- WARNING: unhandled syscall: 340 > > --11114-- You may be able to write your own handler. > > --11114-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > > --11114-- Nevertheless we consider this a bug.  Please report > > --11114-- it at http://valgrind.org/support/bug_reports.html. > > ==11114== Invalid read of size 4 > > ==11114==    at 0x2A68C0: pci_apb_init (apb_pci.c:350) > > ==11114==    by 0x2F7A84: sun4uv_init (sun4u.c:779) > > ==11114==    by 0x13D716: main (vl.c:3397) > > ==11114==  Address 0x156c7d30 is 0 bytes after a block of size 64 > > alloc'd > > ==11114==    at 0x557DD69: malloc (vg_replace_malloc.c:236) > > ==11114==    by 0x225F56: malloc_and_trace (vl.c:2156) > > ==11114==    by 0x584AFEC: ??? (in /lib/libglib-2.0.so.0.2800.8) > > ==11114==    by 0x584B528: g_malloc0 (in /lib/libglib-2.0.so.0.2800.8) > > ==11114==    by 0x19C50C: qemu_allocate_irqs (irq.c:47) > > ==11114==    by 0x2F7A4C: sun4uv_init (sun4u.c:778) > > ==11114==    by 0x13D716: main (vl.c:3397) > > ==11114== > > apb: here > > ==11114== Warning: client switching stacks?  SP change: 0xfec42cbc --> > > 0x16894008 > > ==11114==          to suppress, use: --max-stackframe=398791500 or > > greater > > ==11114== Warning: client switching stacks?  SP change: 0x16893fa0 --> > > 0xfec42cc0 > > ==11114==          to suppress, use: --max-stackframe=398791392 or > > greater > > ==11114== Warning: client switching stacks?  SP change: 0xfec42fe0 --> > > 0x16893fd0 > > ==11114==          to suppress, use: --max-stackframe=398790640 or > > greater > > ==11114==          further instances of this message will not be shown. > > QEMU 1.0.50 monitor - type 'help' for more information > > (qemu) ==11114== Thread 2: > > ==11114== Conditional jump or move depends on uninitialised value(s) > > ==11114==    at 0x2A8351: compute_all_sub (cc_helper.c:37) > > ==11114==    by 0x2A8782: helper_compute_psr (cc_helper.c:470) > > ==11114==    by 0x9AD9A19: ??? > > ==11114== > > ==11114== Conditional jump or move depends on uninitialised value(s) > > ==11114==    at 0x2A827C: compute_all_sub_xcc (cc_helper.c:60) > > ==11114==    by 0x2A8795: helper_compute_psr (cc_helper.c:473) > > ==11114==    by 0x9AD9A19: ??? > > ==11114== > > ==11114== Conditional jump or move depends on uninitialised value(s) > > ==11114==    at 0x2A8296: compute_all_sub_xcc (cc_helper.c:295) > > ==11114==    by 0x2A8795: helper_compute_psr (cc_helper.c:473) > > ==11114==    by 0x9AD9A19: ??? > > ==11114== > > > > Is the above a problem? > > It looks like Sparc does not reset registers at CPU reset. Nice catch. The following is likely also needed, maybe the define should be shared with apb. diff --git a/hw/sun4u.c b/hw/sun4u.c index 423108f..19a135a 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -81,7 +81,7 @@ #define FW_CFG_SPARC64_HEIGHT (FW_CFG_ARCH_LOCAL + 0x01) #define FW_CFG_SPARC64_DEPTH (FW_CFG_ARCH_LOCAL + 0x02) -#define MAX_PILS 16 +#define MAX_PILS 32 #define TICK_MAX 0x7fffffffffffffffULL