Message ID | 20120304094614.GA8158@redhat.com |
---|---|
State | New |
Headers | show |
On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > 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 This unassigned memory exception is triggered because CMD646 IDE I/O registers are not accessible: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 108e:a000 id "" Bus 0, device 1, function 0: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 1. subordinate bus 1. IO range [0x0000, 0x0fff] memory range [0x00000000, 0x000fffff] prefetchable memory range [0x00000000, 0x000fffff] id "" Bus 0, device 1, function 1: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 2. subordinate bus 2. IO range [0x0000, 0x0fff] memory range [0x00000000, 0x000fffff] prefetchable memory range [0x00000000, 0x000fffff] id "" Bus 0, device 2, function 0: VGA controller: PCI device 1234:1111 BAR0: 32 bit prefetchable memory at 0x00800000 [0x00ffffff]. BAR6: 32 bit memory at 0x01000000 [0x0100ffff]. id "" Bus 0, device 3, function 0: Bridge: PCI device 108e:1000 BAR0: 32 bit memory at 0x02000000 [0x02ffffff]. BAR1: 32 bit memory at 0x03000000 [0x037fffff]. id "" Bus 0, device 4, function 0: Ethernet controller: PCI device 10ec:8029 IRQ 0. BAR0: I/O at 0xffffffffffffffff [0x00fe]. BAR6: 32 bit memory at 0x03800000 [0x0380ffff]. id "" Bus 0, device 5, function 0: IDE controller: PCI device 1095:0646 IRQ 1. BAR0: I/O at 0xffffffffffffffff [0x0006]. BAR1: I/O at 0xffffffffffffffff [0x0002]. BAR2: I/O at 0xffffffffffffffff [0x0006]. BAR3: I/O at 0xffffffffffffffff [0x0002]. BAR4: I/O at 0xffffffffffffffff [0x000e]. id "" (qemu) info mtree memory 0000000000000000-7ffffffffffffffe (prio 0, RW): system 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 @vga.vram 0000000000000000-000000000000ffff 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio 000001ff03800000-000001ff0380ffff (prio 1, RW): ne2000.rom 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom pci_bridge_pci 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci pci_bridge_pci 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci vga.vram 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram I/O 0000000000000000-000000000000ffff (prio 0, RW): io 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io @pci_bridge_io 0000000000000000-0000000000000fff 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io @pci_bridge_io 0000000000000000-0000000000000fff 0000000000000060-0000000000000060 (prio 0, RW): i8042-data 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd 0000000000000074-0000000000000077 (prio 0, RW): m48t59 00000000000001ce-00000000000001ce (prio 0, RW): alias vbe @vbe 00000000000001ce-00000000000001ce 00000000000001d0-00000000000001d0 (prio 0, RW): alias vbe @vbe 00000000000001d0-00000000000001d0 0000000000000378-000000000000037f (prio 0, RW): alias parallel @parallel 0000000000000378-000000000000037f 00000000000003b4-00000000000003b5 (prio 0, RW): alias vga @vga 00000000000003b4-00000000000003b5 00000000000003ba-00000000000003ba (prio 0, RW): alias vga @vga 00000000000003ba-00000000000003ba 00000000000003c0-00000000000003cf (prio 0, RW): alias vga @vga 00000000000003c0-00000000000003cf 00000000000003d4-00000000000003d5 (prio 0, RW): alias vga @vga 00000000000003d4-00000000000003d5 00000000000003da-00000000000003da (prio 0, RW): alias vga @vga 00000000000003da-00000000000003da 00000000000003f1-00000000000003f5 (prio 0, RW): alias fdc @fdc 00000000000003f1-00000000000003f5 00000000000003f7-00000000000003f7 (prio 0, RW): alias fdc @fdc 00000000000003f7-00000000000003f7 00000000000003f8-00000000000003ff (prio 0, RW): serial 0000000000000510-0000000000000511 (prio 0, RW): fwcfg > --- > hw/pci.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/pci.c b/hw/pci.c > index fee27fc..6d08cef 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) > memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); > > /* Supported memory and i/o types */ > - d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; > - d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; > + d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; > + d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_BASE, > PCI_PREF_RANGE_TYPE_64); > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_LIMIT, > -- > 1.7.9.111.gf3fb0
On Sun, Mar 04, 2012 at 10:27:24AM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > > 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? > This unassigned memory exception is triggered because CMD646 IDE I/O > registers are not accessible: > > (qemu) info pci > Bus 0, device 0, function 0: > Host bridge: PCI device 108e:a000 > id "" > Bus 0, device 1, function 0: > PCI bridge: PCI device 108e:5000 > BUS 0. > secondary bus 1. > subordinate bus 1. > IO range [0x0000, 0x0fff] > memory range [0x00000000, 0x000fffff] > prefetchable memory range [0x00000000, 0x000fffff] > id "" > Bus 0, device 1, function 1: > PCI bridge: PCI device 108e:5000 > BUS 0. > secondary bus 2. > subordinate bus 2. > IO range [0x0000, 0x0fff] > memory range [0x00000000, 0x000fffff] > prefetchable memory range [0x00000000, 0x000fffff] > id "" > Bus 0, device 2, function 0: > VGA controller: PCI device 1234:1111 > BAR0: 32 bit prefetchable memory at 0x00800000 [0x00ffffff]. > BAR6: 32 bit memory at 0x01000000 [0x0100ffff]. > id "" > Bus 0, device 3, function 0: > Bridge: PCI device 108e:1000 > BAR0: 32 bit memory at 0x02000000 [0x02ffffff]. > BAR1: 32 bit memory at 0x03000000 [0x037fffff]. > id "" > Bus 0, device 4, function 0: > Ethernet controller: PCI device 10ec:8029 > IRQ 0. > BAR0: I/O at 0xffffffffffffffff [0x00fe]. > BAR6: 32 bit memory at 0x03800000 [0x0380ffff]. > id "" > Bus 0, device 5, function 0: > IDE controller: PCI device 1095:0646 > IRQ 1. > BAR0: I/O at 0xffffffffffffffff [0x0006]. > BAR1: I/O at 0xffffffffffffffff [0x0002]. > BAR2: I/O at 0xffffffffffffffff [0x0006]. > BAR3: I/O at 0xffffffffffffffff [0x0002]. > BAR4: I/O at 0xffffffffffffffff [0x000e]. > id "" > (qemu) info mtree > memory > 0000000000000000-7ffffffffffffffe (prio 0, RW): system > 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram > 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config > 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config > 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport > 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 > @vga.vram 0000000000000000-000000000000ffff > 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem > 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram > 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom > 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio > 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio > 000001ff03800000-000001ff0380ffff (prio 1, RW): ne2000.rom > 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom > pci_bridge_pci > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > pci_bridge_pci > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > vga.vram > 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram > I/O > 0000000000000000-000000000000ffff (prio 0, RW): io > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > @pci_bridge_io 0000000000000000-0000000000000fff > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > @pci_bridge_io 0000000000000000-0000000000000fff > 0000000000000060-0000000000000060 (prio 0, RW): i8042-data > 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd > 0000000000000074-0000000000000077 (prio 0, RW): m48t59 > 00000000000001ce-00000000000001ce (prio 0, RW): alias vbe @vbe > 00000000000001ce-00000000000001ce > 00000000000001d0-00000000000001d0 (prio 0, RW): alias vbe @vbe > 00000000000001d0-00000000000001d0 > 0000000000000378-000000000000037f (prio 0, RW): alias parallel > @parallel 0000000000000378-000000000000037f > 00000000000003b4-00000000000003b5 (prio 0, RW): alias vga @vga > 00000000000003b4-00000000000003b5 > 00000000000003ba-00000000000003ba (prio 0, RW): alias vga @vga > 00000000000003ba-00000000000003ba > 00000000000003c0-00000000000003cf (prio 0, RW): alias vga @vga > 00000000000003c0-00000000000003cf > 00000000000003d4-00000000000003d5 (prio 0, RW): alias vga @vga > 00000000000003d4-00000000000003d5 > 00000000000003da-00000000000003da (prio 0, RW): alias vga @vga > 00000000000003da-00000000000003da > 00000000000003f1-00000000000003f5 (prio 0, RW): alias fdc @fdc > 00000000000003f1-00000000000003f5 > 00000000000003f7-00000000000003f7 (prio 0, RW): alias fdc @fdc > 00000000000003f7-00000000000003f7 > 00000000000003f8-00000000000003ff (prio 0, RW): serial > 0000000000000510-0000000000000511 (prio 0, RW): fwcfg And with type 32 range it looks like this: 0000000000000000-7ffffffffffffffe (prio 0, RW): system 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 @vga.vram 0000000000000000-000000000000ffff 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom pci_bridge_pci 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci pci_bridge_pci 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci vga.vram 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram I/O 0000000000000000-000000000000ffff (prio 0, RW): io 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io @pci_bridge_io 0000000000000000-0000000000000fff 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io @pci_bridge_io 0000000000000000-0000000000000fff 0000000000000060-0000000000000060 (prio 0, RW): i8042-data 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd 0000000000000074-0000000000000077 (prio 0, RW): m48t59 00000000000001ce-00000000000001ce (prio 0, RW): vbe 00000000000001d0-00000000000001d0 (prio 0, RW): vbe 0000000000000378-000000000000037f (prio 0, RW): parallel 00000000000003b4-00000000000003b5 (prio 0, RW): vga 00000000000003ba-00000000000003ba (prio 0, RW): vga 00000000000003c0-00000000000003cf (prio 0, RW): vga 00000000000003d4-00000000000003d5 (prio 0, RW): vga 00000000000003da-00000000000003da (prio 0, RW): vga 00000000000003f1-00000000000003f5 (prio 0, RW): fdc 00000000000003f7-00000000000003f7 (prio 0, RW): fdc 00000000000003f8-00000000000003ff (prio 0, RW): serial 0000000000000400-00000000000004ff (prio 1, RW): ne2000 0000000000000500-0000000000000507 (prio 1, RW): cmd646-data 0000000000000510-0000000000000511 (prio 0, RW): fwcfg 0000000000000580-0000000000000583 (prio 1, RW): cmd646-cmd 0000000000000600-0000000000000607 (prio 1, RW): cmd646-data 0000000000000680-0000000000000683 (prio 1, RW): cmd646-cmd 0000000000000700-000000000000070f (prio 1, RW): cmd646-bmdma 0000000000000700-0000000000000703 (prio 0, RW): cmd646-bmdma-bus 0000000000000704-0000000000000707 (prio 0, RW): cmd646-bmdma-ioport 0000000000000708-000000000000070b (prio 0, RW): cmd646-bmdma-bus 000000000000070c-000000000000070f (prio 0, RW): cmd646-bmdma-ioport Sill trying to understand what all this means. > > hw/pci.c | 4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/hw/pci.c b/hw/pci.c > > index fee27fc..6d08cef 100644 > > --- a/hw/pci.c > > +++ b/hw/pci.c > > @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) > > memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); > > > > /* Supported memory and i/o types */ > > - d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; > > - d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; > > + d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; > > + d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; > > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_BASE, > > PCI_PREF_RANGE_TYPE_64); > > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_LIMIT, > > -- > > 1.7.9.111.gf3fb0
On 03/04/2012 12:27 PM, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > > 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 > > This unassigned memory exception is triggered because CMD646 IDE I/O > registers are not accessible: > > (qemu) info pci > Bus 0, device 5, function 0: > IDE controller: PCI device 1095:0646 > IRQ 1. > BAR0: I/O at 0xffffffffffffffff [0x0006]. > BAR1: I/O at 0xffffffffffffffff [0x0002]. > BAR2: I/O at 0xffffffffffffffff [0x0006]. > BAR3: I/O at 0xffffffffffffffff [0x0002]. > BAR4: I/O at 0xffffffffffffffff [0x000e]. > id "" The BARs are not initialized, so they aren't accessible. But perhaps the dump was not taken at the point of failure, can you provide a relevant dump if so?
On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> >> > >> > 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. >> This unassigned memory exception is triggered because CMD646 IDE I/O >> registers are not accessible: >> >> (qemu) info pci >> Bus 0, device 0, function 0: >> Host bridge: PCI device 108e:a000 >> id "" >> Bus 0, device 1, function 0: >> PCI bridge: PCI device 108e:5000 >> BUS 0. >> secondary bus 1. >> subordinate bus 1. >> IO range [0x0000, 0x0fff] >> memory range [0x00000000, 0x000fffff] >> prefetchable memory range [0x00000000, 0x000fffff] >> id "" >> Bus 0, device 1, function 1: >> PCI bridge: PCI device 108e:5000 >> BUS 0. >> secondary bus 2. >> subordinate bus 2. >> IO range [0x0000, 0x0fff] >> memory range [0x00000000, 0x000fffff] >> prefetchable memory range [0x00000000, 0x000fffff] >> id "" >> Bus 0, device 2, function 0: >> VGA controller: PCI device 1234:1111 >> BAR0: 32 bit prefetchable memory at 0x00800000 [0x00ffffff]. >> BAR6: 32 bit memory at 0x01000000 [0x0100ffff]. >> id "" >> Bus 0, device 3, function 0: >> Bridge: PCI device 108e:1000 >> BAR0: 32 bit memory at 0x02000000 [0x02ffffff]. >> BAR1: 32 bit memory at 0x03000000 [0x037fffff]. >> id "" >> Bus 0, device 4, function 0: >> Ethernet controller: PCI device 10ec:8029 >> IRQ 0. >> BAR0: I/O at 0xffffffffffffffff [0x00fe]. >> BAR6: 32 bit memory at 0x03800000 [0x0380ffff]. >> id "" >> Bus 0, device 5, function 0: >> IDE controller: PCI device 1095:0646 >> IRQ 1. >> BAR0: I/O at 0xffffffffffffffff [0x0006]. >> BAR1: I/O at 0xffffffffffffffff [0x0002]. >> BAR2: I/O at 0xffffffffffffffff [0x0006]. >> BAR3: I/O at 0xffffffffffffffff [0x0002]. >> BAR4: I/O at 0xffffffffffffffff [0x000e]. >> id "" >> (qemu) info mtree >> memory >> 0000000000000000-7ffffffffffffffe (prio 0, RW): system >> 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram >> 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config >> 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config >> 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport >> 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 >> @vga.vram 0000000000000000-000000000000ffff >> 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem >> 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram >> 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom >> 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio >> 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio >> 000001ff03800000-000001ff0380ffff (prio 1, RW): ne2000.rom >> 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom >> pci_bridge_pci >> 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci >> pci_bridge_pci >> 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci >> vga.vram >> 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram >> I/O >> 0000000000000000-000000000000ffff (prio 0, RW): io >> 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io >> @pci_bridge_io 0000000000000000-0000000000000fff >> 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io >> @pci_bridge_io 0000000000000000-0000000000000fff >> 0000000000000060-0000000000000060 (prio 0, RW): i8042-data >> 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd >> 0000000000000074-0000000000000077 (prio 0, RW): m48t59 >> 00000000000001ce-00000000000001ce (prio 0, RW): alias vbe @vbe >> 00000000000001ce-00000000000001ce >> 00000000000001d0-00000000000001d0 (prio 0, RW): alias vbe @vbe >> 00000000000001d0-00000000000001d0 >> 0000000000000378-000000000000037f (prio 0, RW): alias parallel >> @parallel 0000000000000378-000000000000037f >> 00000000000003b4-00000000000003b5 (prio 0, RW): alias vga @vga >> 00000000000003b4-00000000000003b5 >> 00000000000003ba-00000000000003ba (prio 0, RW): alias vga @vga >> 00000000000003ba-00000000000003ba >> 00000000000003c0-00000000000003cf (prio 0, RW): alias vga @vga >> 00000000000003c0-00000000000003cf >> 00000000000003d4-00000000000003d5 (prio 0, RW): alias vga @vga >> 00000000000003d4-00000000000003d5 >> 00000000000003da-00000000000003da (prio 0, RW): alias vga @vga >> 00000000000003da-00000000000003da >> 00000000000003f1-00000000000003f5 (prio 0, RW): alias fdc @fdc >> 00000000000003f1-00000000000003f5 >> 00000000000003f7-00000000000003f7 (prio 0, RW): alias fdc @fdc >> 00000000000003f7-00000000000003f7 >> 00000000000003f8-00000000000003ff (prio 0, RW): serial >> 0000000000000510-0000000000000511 (prio 0, RW): fwcfg > > And with type 32 range it looks like this: > > 0000000000000000-7ffffffffffffffe (prio 0, RW): system > 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram > 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config > 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config > 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport > 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio > 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 > @vga.vram 0000000000000000-000000000000ffff > 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem > 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram > 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom > 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio > 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio > 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom > pci_bridge_pci > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > pci_bridge_pci > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > vga.vram > 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram > I/O > 0000000000000000-000000000000ffff (prio 0, RW): io > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > @pci_bridge_io 0000000000000000-0000000000000fff > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > @pci_bridge_io 0000000000000000-0000000000000fff > 0000000000000060-0000000000000060 (prio 0, RW): i8042-data > 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd > 0000000000000074-0000000000000077 (prio 0, RW): m48t59 > 00000000000001ce-00000000000001ce (prio 0, RW): vbe > 00000000000001d0-00000000000001d0 (prio 0, RW): vbe > 0000000000000378-000000000000037f (prio 0, RW): parallel > 00000000000003b4-00000000000003b5 (prio 0, RW): vga > 00000000000003ba-00000000000003ba (prio 0, RW): vga > 00000000000003c0-00000000000003cf (prio 0, RW): vga > 00000000000003d4-00000000000003d5 (prio 0, RW): vga > 00000000000003da-00000000000003da (prio 0, RW): vga > 00000000000003f1-00000000000003f5 (prio 0, RW): fdc > 00000000000003f7-00000000000003f7 (prio 0, RW): fdc > 00000000000003f8-00000000000003ff (prio 0, RW): serial > 0000000000000400-00000000000004ff (prio 1, RW): ne2000 > 0000000000000500-0000000000000507 (prio 1, RW): cmd646-data > 0000000000000510-0000000000000511 (prio 0, RW): fwcfg > 0000000000000580-0000000000000583 (prio 1, RW): cmd646-cmd > 0000000000000600-0000000000000607 (prio 1, RW): cmd646-data > 0000000000000680-0000000000000683 (prio 1, RW): cmd646-cmd > 0000000000000700-000000000000070f (prio 1, RW): cmd646-bmdma > 0000000000000700-0000000000000703 (prio 0, RW): cmd646-bmdma-bus > 0000000000000704-0000000000000707 (prio 0, RW): cmd646-bmdma-ioport > 0000000000000708-000000000000070b (prio 0, RW): cmd646-bmdma-bus > 000000000000070c-000000000000070f (prio 0, RW): cmd646-bmdma-ioport This looks better. > > Sill trying to understand what all this means. > > >> > hw/pci.c | 4 ++-- >> > 1 files changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/hw/pci.c b/hw/pci.c >> > index fee27fc..6d08cef 100644 >> > --- a/hw/pci.c >> > +++ b/hw/pci.c >> > @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) >> > memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); >> > >> > /* Supported memory and i/o types */ >> > - d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; >> > - d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; >> > + d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; >> > + d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; >> > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_BASE, >> > PCI_PREF_RANGE_TYPE_64); >> > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_LIMIT, >> > -- >> > 1.7.9.111.gf3fb0
On Sun, Mar 4, 2012 at 12:28, Avi Kivity <avi@redhat.com> wrote: > On 03/04/2012 12:27 PM, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> >> > >> > 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 >> >> This unassigned memory exception is triggered because CMD646 IDE I/O >> registers are not accessible: >> >> (qemu) info pci >> Bus 0, device 5, function 0: >> IDE controller: PCI device 1095:0646 >> IRQ 1. >> BAR0: I/O at 0xffffffffffffffff [0x0006]. >> BAR1: I/O at 0xffffffffffffffff [0x0002]. >> BAR2: I/O at 0xffffffffffffffff [0x0006]. >> BAR3: I/O at 0xffffffffffffffff [0x0002]. >> BAR4: I/O at 0xffffffffffffffff [0x000e]. >> id "" > > The BARs are not initialized, so they aren't accessible. > > But perhaps the dump was not taken at the point of failure, can you > provide a relevant dump if so? No, this is after failure. > > -- > error compiling committee.c: too many arguments to function >
On 03/04/2012 02:38 PM, Blue Swirl wrote: > >> > >> This unassigned memory exception is triggered because CMD646 IDE I/O > >> registers are not accessible: > >> > >> (qemu) info pci > >> Bus 0, device 5, function 0: > >> IDE controller: PCI device 1095:0646 > >> IRQ 1. > >> BAR0: I/O at 0xffffffffffffffff [0x0006]. > >> BAR1: I/O at 0xffffffffffffffff [0x0002]. > >> BAR2: I/O at 0xffffffffffffffff [0x0006]. > >> BAR3: I/O at 0xffffffffffffffff [0x0002]. > >> BAR4: I/O at 0xffffffffffffffff [0x000e]. > >> id "" > > > > The BARs are not initialized, so they aren't accessible. > > > > But perhaps the dump was not taken at the point of failure, can you > > provide a relevant dump if so? > > No, this is after failure. I don't see why the guest expects the BARs to work then.
On Sun, Mar 4, 2012 at 12:41, Avi Kivity <avi@redhat.com> wrote: > On 03/04/2012 02:38 PM, Blue Swirl wrote: >> >> >> >> This unassigned memory exception is triggered because CMD646 IDE I/O >> >> registers are not accessible: >> >> >> >> (qemu) info pci >> >> Bus 0, device 5, function 0: >> >> IDE controller: PCI device 1095:0646 >> >> IRQ 1. >> >> BAR0: I/O at 0xffffffffffffffff [0x0006]. >> >> BAR1: I/O at 0xffffffffffffffff [0x0002]. >> >> BAR2: I/O at 0xffffffffffffffff [0x0006]. >> >> BAR3: I/O at 0xffffffffffffffff [0x0002]. >> >> BAR4: I/O at 0xffffffffffffffff [0x000e]. >> >> id "" >> > >> > The BARs are not initialized, so they aren't accessible. >> > >> > But perhaps the dump was not taken at the point of failure, can you >> > provide a relevant dump if so? >> >> No, this is after failure. > > I don't see why the guest expects the BARs to work then. OpenBIOS could initialize them before this commit, now it obviously can't (or initializes the bridges incorrectly). Maybe also the devices should be moved behind the bridges, that's where they really should be. > > -- > error compiling committee.c: too many arguments to function >
On Sun, Mar 04, 2012 at 12:46:23PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 12:41, Avi Kivity <avi@redhat.com> wrote: > > On 03/04/2012 02:38 PM, Blue Swirl wrote: > >> >> > >> >> This unassigned memory exception is triggered because CMD646 IDE I/O > >> >> registers are not accessible: > >> >> > >> >> (qemu) info pci > >> >> Bus 0, device 5, function 0: > >> >> IDE controller: PCI device 1095:0646 > >> >> IRQ 1. > >> >> BAR0: I/O at 0xffffffffffffffff [0x0006]. > >> >> BAR1: I/O at 0xffffffffffffffff [0x0002]. > >> >> BAR2: I/O at 0xffffffffffffffff [0x0006]. > >> >> BAR3: I/O at 0xffffffffffffffff [0x0002]. > >> >> BAR4: I/O at 0xffffffffffffffff [0x000e]. > >> >> id "" > >> > > >> > The BARs are not initialized, so they aren't accessible. > >> > > >> > But perhaps the dump was not taken at the point of failure, can you > >> > provide a relevant dump if so? > >> > >> No, this is after failure. > > > > I don't see why the guest expects the BARs to work then. > > OpenBIOS could initialize them before this commit, now it obviously > can't (or initializes the bridges incorrectly). I traced all config reads and writes to the bridge and there's no difference I can see between before and after this commit. I think there's some other bug, tweaking this specific bit just happens to trigger it. > Maybe also the devices should be moved behind the bridges, that's > where they really should be. > > > > > -- > > error compiling committee.c: too many arguments to function > >
On Sun, Mar 04, 2012 at 02:41:33PM +0200, Avi Kivity wrote: > On 03/04/2012 02:38 PM, Blue Swirl wrote: > > >> > > >> This unassigned memory exception is triggered because CMD646 IDE I/O > > >> registers are not accessible: > > >> > > >> (qemu) info pci > > >> Bus 0, device 5, function 0: > > >> IDE controller: PCI device 1095:0646 > > >> IRQ 1. > > >> BAR0: I/O at 0xffffffffffffffff [0x0006]. > > >> BAR1: I/O at 0xffffffffffffffff [0x0002]. > > >> BAR2: I/O at 0xffffffffffffffff [0x0006]. > > >> BAR3: I/O at 0xffffffffffffffff [0x0002]. > > >> BAR4: I/O at 0xffffffffffffffff [0x000e]. > > >> id "" > > > > > > The BARs are not initialized, so they aren't accessible. > > > > > > But perhaps the dump was not taken at the point of failure, can you > > > provide a relevant dump if so? > > > > No, this is after failure. > > I don't see why the guest expects the BARs to work then. I don't belive it does - it probably got hang before initializing BARs. > -- > error compiling committee.c: too many arguments to function
On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > >> > > >> > 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. Invalid read and address after block are also worrying. irqs are allocated with #define MAX_PILS 16 irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); then passed to apb: pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, &pci_bus3); which does: PCIBus *pci_apb_init(target_phys_addr_t special_base, target_phys_addr_t mem_base, qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) and for (i = 0; i < 32; i++) { sysbus_connect_irq(s, i, pic[i]); } > >> This unassigned memory exception is triggered because CMD646 IDE I/O > >> registers are not accessible: > >> > >> (qemu) info pci > >> Bus 0, device 0, function 0: > >> Host bridge: PCI device 108e:a000 > >> id "" > >> Bus 0, device 1, function 0: > >> PCI bridge: PCI device 108e:5000 > >> BUS 0. > >> secondary bus 1. > >> subordinate bus 1. > >> IO range [0x0000, 0x0fff] > >> memory range [0x00000000, 0x000fffff] > >> prefetchable memory range [0x00000000, 0x000fffff] > >> id "" > >> Bus 0, device 1, function 1: > >> PCI bridge: PCI device 108e:5000 > >> BUS 0. > >> secondary bus 2. > >> subordinate bus 2. > >> IO range [0x0000, 0x0fff] > >> memory range [0x00000000, 0x000fffff] > >> prefetchable memory range [0x00000000, 0x000fffff] > >> id "" > >> Bus 0, device 2, function 0: > >> VGA controller: PCI device 1234:1111 > >> BAR0: 32 bit prefetchable memory at 0x00800000 [0x00ffffff]. > >> BAR6: 32 bit memory at 0x01000000 [0x0100ffff]. > >> id "" > >> Bus 0, device 3, function 0: > >> Bridge: PCI device 108e:1000 > >> BAR0: 32 bit memory at 0x02000000 [0x02ffffff]. > >> BAR1: 32 bit memory at 0x03000000 [0x037fffff]. > >> id "" > >> Bus 0, device 4, function 0: > >> Ethernet controller: PCI device 10ec:8029 > >> IRQ 0. > >> BAR0: I/O at 0xffffffffffffffff [0x00fe]. > >> BAR6: 32 bit memory at 0x03800000 [0x0380ffff]. > >> id "" > >> Bus 0, device 5, function 0: > >> IDE controller: PCI device 1095:0646 > >> IRQ 1. > >> BAR0: I/O at 0xffffffffffffffff [0x0006]. > >> BAR1: I/O at 0xffffffffffffffff [0x0002]. > >> BAR2: I/O at 0xffffffffffffffff [0x0006]. > >> BAR3: I/O at 0xffffffffffffffff [0x0002]. > >> BAR4: I/O at 0xffffffffffffffff [0x000e]. > >> id "" > >> (qemu) info mtree > >> memory > >> 0000000000000000-7ffffffffffffffe (prio 0, RW): system > >> 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram > >> 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config > >> 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config > >> 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport > >> 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio > >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias > >> pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff > >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias > >> pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias > >> pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff > >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias > >> pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > >> 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 > >> @vga.vram 0000000000000000-000000000000ffff > >> 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem > >> 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram > >> 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom > >> 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio > >> 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio > >> 000001ff03800000-000001ff0380ffff (prio 1, RW): ne2000.rom > >> 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom > >> pci_bridge_pci > >> 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > >> pci_bridge_pci > >> 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > >> vga.vram > >> 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram > >> I/O > >> 0000000000000000-000000000000ffff (prio 0, RW): io > >> 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > >> @pci_bridge_io 0000000000000000-0000000000000fff > >> 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > >> @pci_bridge_io 0000000000000000-0000000000000fff > >> 0000000000000060-0000000000000060 (prio 0, RW): i8042-data > >> 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd > >> 0000000000000074-0000000000000077 (prio 0, RW): m48t59 > >> 00000000000001ce-00000000000001ce (prio 0, RW): alias vbe @vbe > >> 00000000000001ce-00000000000001ce > >> 00000000000001d0-00000000000001d0 (prio 0, RW): alias vbe @vbe > >> 00000000000001d0-00000000000001d0 > >> 0000000000000378-000000000000037f (prio 0, RW): alias parallel > >> @parallel 0000000000000378-000000000000037f > >> 00000000000003b4-00000000000003b5 (prio 0, RW): alias vga @vga > >> 00000000000003b4-00000000000003b5 > >> 00000000000003ba-00000000000003ba (prio 0, RW): alias vga @vga > >> 00000000000003ba-00000000000003ba > >> 00000000000003c0-00000000000003cf (prio 0, RW): alias vga @vga > >> 00000000000003c0-00000000000003cf > >> 00000000000003d4-00000000000003d5 (prio 0, RW): alias vga @vga > >> 00000000000003d4-00000000000003d5 > >> 00000000000003da-00000000000003da (prio 0, RW): alias vga @vga > >> 00000000000003da-00000000000003da > >> 00000000000003f1-00000000000003f5 (prio 0, RW): alias fdc @fdc > >> 00000000000003f1-00000000000003f5 > >> 00000000000003f7-00000000000003f7 (prio 0, RW): alias fdc @fdc > >> 00000000000003f7-00000000000003f7 > >> 00000000000003f8-00000000000003ff (prio 0, RW): serial > >> 0000000000000510-0000000000000511 (prio 0, RW): fwcfg > > > > And with type 32 range it looks like this: > > > > 0000000000000000-7ffffffffffffffe (prio 0, RW): system > > 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram > > 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config > > 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config > > 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport > > 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio > > 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem > > @pci_bridge_pci 0000000000000000-00000000000fffff > > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > > 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem > > @pci_bridge_pci 0000000000000000-00000000000fffff > > 000001ff00000000-000001ff000fffff (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff > > 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 > > @vga.vram 0000000000000000-000000000000ffff > > 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem > > 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram > > 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom > > 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio > > 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio > > 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom > > pci_bridge_pci > > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > > pci_bridge_pci > > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci > > vga.vram > > 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram > > I/O > > 0000000000000000-000000000000ffff (prio 0, RW): io > > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > > @pci_bridge_io 0000000000000000-0000000000000fff > > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io > > @pci_bridge_io 0000000000000000-0000000000000fff > > 0000000000000060-0000000000000060 (prio 0, RW): i8042-data > > 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd > > 0000000000000074-0000000000000077 (prio 0, RW): m48t59 > > 00000000000001ce-00000000000001ce (prio 0, RW): vbe > > 00000000000001d0-00000000000001d0 (prio 0, RW): vbe > > 0000000000000378-000000000000037f (prio 0, RW): parallel > > 00000000000003b4-00000000000003b5 (prio 0, RW): vga > > 00000000000003ba-00000000000003ba (prio 0, RW): vga > > 00000000000003c0-00000000000003cf (prio 0, RW): vga > > 00000000000003d4-00000000000003d5 (prio 0, RW): vga > > 00000000000003da-00000000000003da (prio 0, RW): vga > > 00000000000003f1-00000000000003f5 (prio 0, RW): fdc > > 00000000000003f7-00000000000003f7 (prio 0, RW): fdc > > 00000000000003f8-00000000000003ff (prio 0, RW): serial > > 0000000000000400-00000000000004ff (prio 1, RW): ne2000 > > 0000000000000500-0000000000000507 (prio 1, RW): cmd646-data > > 0000000000000510-0000000000000511 (prio 0, RW): fwcfg > > 0000000000000580-0000000000000583 (prio 1, RW): cmd646-cmd > > 0000000000000600-0000000000000607 (prio 1, RW): cmd646-data > > 0000000000000680-0000000000000683 (prio 1, RW): cmd646-cmd > > 0000000000000700-000000000000070f (prio 1, RW): cmd646-bmdma > > 0000000000000700-0000000000000703 (prio 0, RW): cmd646-bmdma-bus > > 0000000000000704-0000000000000707 (prio 0, RW): cmd646-bmdma-ioport > > 0000000000000708-000000000000070b (prio 0, RW): cmd646-bmdma-bus > > 000000000000070c-000000000000070f (prio 0, RW): cmd646-bmdma-ioport > > This looks better. > > > > > Sill trying to understand what all this means. > > > > > >> > hw/pci.c | 4 ++-- > >> > 1 files changed, 2 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/hw/pci.c b/hw/pci.c > >> > index fee27fc..6d08cef 100644 > >> > --- a/hw/pci.c > >> > +++ b/hw/pci.c > >> > @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) > >> > memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); > >> > > >> > /* Supported memory and i/o types */ > >> > - d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; > >> > - d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; > >> > + d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; > >> > + d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; > >> > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_BASE, > >> > PCI_PREF_RANGE_TYPE_64); > >> > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_LIMIT, > >> > -- > >> > 1.7.9.111.gf3fb0
On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> >> >> > >> >> > 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. > > Invalid read and address after block are also worrying. > > irqs are allocated with > #define MAX_PILS 16 > > irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); > > then passed to apb: > > pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, > &pci_bus3); > > which does: > PCIBus *pci_apb_init(target_phys_addr_t special_base, > target_phys_addr_t mem_base, > qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) > > and > > for (i = 0; i < 32; i++) { > sysbus_connect_irq(s, i, pic[i]); > } Awful. But using 32 for MAX_PILS does not help either. I get this with a modified OpenBIOS and no secondary bridges: OpenBIOS for Sparc64 Initializing PCI host bridge... pci_host_set_reg reg 000001FE 00000000 00000000 02000000 === CHANGED === package path old=/pci new=/pci@1fe,0 0:0.0 - 108e:a000 - host bridge found - /pci@1fe,0 - pci_host_set_reg reg 000001FE 00000000 00000000 02000000 scanning new pci bus 0 under bridge /pci@1fe,0 Scanning bus 0 at /pci@1fe,0... 0:0.0 - 108e:a000 - host bridge found - /pci@1fe,0 - host bridge already configured 0:1.0 - 1234:1111 - /pci@1fe,0/QEMU,VGA - ob_pci_encode_unit space=0 dev=1 fn=0 buf=1 === CHANGED === package path old=/pci@1fe,0/QEMU,VGA new=/pci@1fe,0/QEMU,VGA@1 pci_set_reg reg 00000800 00000000 00000000 00000000 00000000 42000810 00000000 00000000 00000000 00800000 ob_pci_decode_unit idx=00000000ffe8be08 ob_pci_decode_unit idx=00000000ffe8be08 addr=0000000000000000 0000000000000000 0000000000000800 0:2.0 - 108e:1000 - /pci@1fe,0/ebus - ob_pci_encode_unit space=0 dev=2 fn=0 buf=2 === CHANGED === package path old=/pci@1fe,0/ebus new=/pci@1fe,0/ebus@2 pci_set_reg reg 00001000 00000000 00000000 00000000 00000000 02001010 00000000 00000000 00000000 01000000 02001014 00000000 00000000 00000000 00800000 ob_pci_decode_unit idx=00000000ffe29248 ob_pci_decode_unit idx=00000000ffe29248 addr=0000000000000000 0000000000000000 0000000000001000 ob_pci_decode_unit idx=00000000ffe29248 ob_pci_decode_unit idx=00000000ffe29248 addr=0000000000000000 0000000000000000 0000000000001000 ob_pci_decode_unit idx=00000000ffe29248 ob_pci_decode_unit idx=00000000ffe29248 addr=0000000000000000 0000000000000000 0000000000001000 ob_pci_decode_unit idx=00000000ffe29248 ob_pci_decode_unit idx=00000000ffe29248 addr=0000000000000000 0000000000000000 0000000000001000 ob_pci_decode_unit idx=00000000ffe29248 ob_pci_decode_unit idx=00000000ffe29248 addr=0000000000000000 0000000000000000 0000000000001000 ob_pci_decode_unit idx=00000000ffe29248 ob_pci_decode_unit idx=00000000ffe29248 addr=0000000000000000 0000000000000000 0000000000001000 ob_pci_decode_unit idx=00000000ffe8bf38 ob_pci_decode_unit idx=00000000ffe8bf38 addr=0000000000000000 0000000000000000 0000000000001000 0:3.0 - 10ec:8029 - /pci@1fe,0/NE2000 - ob_pci_encode_unit space=0 dev=3 fn=0 buf=3 === CHANGED === package path old=/pci@1fe,0/NE2000 new=/pci@1fe,0/NE2000@3 pci_set_reg reg 00001800 00000000 00000000 00000000 00000000 01001810 00000000 00000000 00000000 00000100 0:4.0 - 1095:646 - /pci@1fe,0/pci-ata - ob_pci_encode_unit space=0 dev=4 fn=0 buf=4 === CHANGED === package path old=/pci@1fe,0/pci-ata new=/pci@1fe,0/pci-ata@4 pci_set_reg reg 00002000 00000000 00000000 00000000 00000000 01002010 00000000 00000000 00000000 00000008 01002014 00000000 00000000 00000000 00000004 01002018 00000000 00000000 00000000 00000008 0100201C 00000000 00000000 00000000 00000004 01002020 00000000 00000000 00000000 00000010 Unhandled Exception 0x0000000000000032 PC = 0x00000000ffd1a1e4 NPC = 0x00000000ffd1a1e8 Stopping execution QEMU 1.0.50 monitor - type 'help' for more information > > >> >> This unassigned memory exception is triggered because CMD646 IDE I/O >> >> registers are not accessible: >> >> >> >> (qemu) info pci >> >> Bus 0, device 0, function 0: >> >> Host bridge: PCI device 108e:a000 >> >> id "" >> >> Bus 0, device 1, function 0: >> >> PCI bridge: PCI device 108e:5000 >> >> BUS 0. >> >> secondary bus 1. >> >> subordinate bus 1. >> >> IO range [0x0000, 0x0fff] >> >> memory range [0x00000000, 0x000fffff] >> >> prefetchable memory range [0x00000000, 0x000fffff] >> >> id "" >> >> Bus 0, device 1, function 1: >> >> PCI bridge: PCI device 108e:5000 >> >> BUS 0. >> >> secondary bus 2. >> >> subordinate bus 2. >> >> IO range [0x0000, 0x0fff] >> >> memory range [0x00000000, 0x000fffff] >> >> prefetchable memory range [0x00000000, 0x000fffff] >> >> id "" >> >> Bus 0, device 2, function 0: >> >> VGA controller: PCI device 1234:1111 >> >> BAR0: 32 bit prefetchable memory at 0x00800000 [0x00ffffff]. >> >> BAR6: 32 bit memory at 0x01000000 [0x0100ffff]. >> >> id "" >> >> Bus 0, device 3, function 0: >> >> Bridge: PCI device 108e:1000 >> >> BAR0: 32 bit memory at 0x02000000 [0x02ffffff]. >> >> BAR1: 32 bit memory at 0x03000000 [0x037fffff]. >> >> id "" >> >> Bus 0, device 4, function 0: >> >> Ethernet controller: PCI device 10ec:8029 >> >> IRQ 0. >> >> BAR0: I/O at 0xffffffffffffffff [0x00fe]. >> >> BAR6: 32 bit memory at 0x03800000 [0x0380ffff]. >> >> id "" >> >> Bus 0, device 5, function 0: >> >> IDE controller: PCI device 1095:0646 >> >> IRQ 1. >> >> BAR0: I/O at 0xffffffffffffffff [0x0006]. >> >> BAR1: I/O at 0xffffffffffffffff [0x0002]. >> >> BAR2: I/O at 0xffffffffffffffff [0x0006]. >> >> BAR3: I/O at 0xffffffffffffffff [0x0002]. >> >> BAR4: I/O at 0xffffffffffffffff [0x000e]. >> >> id "" >> >> (qemu) info mtree >> >> memory >> >> 0000000000000000-7ffffffffffffffe (prio 0, RW): system >> >> 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram >> >> 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config >> >> 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config >> >> 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport >> >> 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio >> >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> >> pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> >> pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> >> pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> >> 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> >> pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> >> 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 >> >> @vga.vram 0000000000000000-000000000000ffff >> >> 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem >> >> 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram >> >> 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom >> >> 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio >> >> 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio >> >> 000001ff03800000-000001ff0380ffff (prio 1, RW): ne2000.rom >> >> 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom >> >> pci_bridge_pci >> >> 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci >> >> pci_bridge_pci >> >> 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci >> >> vga.vram >> >> 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram >> >> I/O >> >> 0000000000000000-000000000000ffff (prio 0, RW): io >> >> 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io >> >> @pci_bridge_io 0000000000000000-0000000000000fff >> >> 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io >> >> @pci_bridge_io 0000000000000000-0000000000000fff >> >> 0000000000000060-0000000000000060 (prio 0, RW): i8042-data >> >> 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd >> >> 0000000000000074-0000000000000077 (prio 0, RW): m48t59 >> >> 00000000000001ce-00000000000001ce (prio 0, RW): alias vbe @vbe >> >> 00000000000001ce-00000000000001ce >> >> 00000000000001d0-00000000000001d0 (prio 0, RW): alias vbe @vbe >> >> 00000000000001d0-00000000000001d0 >> >> 0000000000000378-000000000000037f (prio 0, RW): alias parallel >> >> @parallel 0000000000000378-000000000000037f >> >> 00000000000003b4-00000000000003b5 (prio 0, RW): alias vga @vga >> >> 00000000000003b4-00000000000003b5 >> >> 00000000000003ba-00000000000003ba (prio 0, RW): alias vga @vga >> >> 00000000000003ba-00000000000003ba >> >> 00000000000003c0-00000000000003cf (prio 0, RW): alias vga @vga >> >> 00000000000003c0-00000000000003cf >> >> 00000000000003d4-00000000000003d5 (prio 0, RW): alias vga @vga >> >> 00000000000003d4-00000000000003d5 >> >> 00000000000003da-00000000000003da (prio 0, RW): alias vga @vga >> >> 00000000000003da-00000000000003da >> >> 00000000000003f1-00000000000003f5 (prio 0, RW): alias fdc @fdc >> >> 00000000000003f1-00000000000003f5 >> >> 00000000000003f7-00000000000003f7 (prio 0, RW): alias fdc @fdc >> >> 00000000000003f7-00000000000003f7 >> >> 00000000000003f8-00000000000003ff (prio 0, RW): serial >> >> 0000000000000510-0000000000000511 (prio 0, RW): fwcfg >> > >> > And with type 32 range it looks like this: >> > >> > 0000000000000000-7ffffffffffffffe (prio 0, RW): system >> > 0000000000000000-0000000007ffffff (prio 0, RW): sun4u.ram >> > 000001fe00000000-000001fe0000ffff (prio 0, RW): apb-config >> > 000001fe01000000-000001fe01ffffff (prio 0, RW): apb-pci-config >> > 000001fe02000000-000001fe0200ffff (prio 0, RW): apb-pci-ioport >> > 000001ff00000000-000001ffffffffff (prio 0, RW): pci-mmio >> > 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem >> > @pci_bridge_pci 0000000000000000-00000000000fffff >> > 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> > 000001ff00000000-000001ff000fffff (prio 1, RW): alias pci_bridge_mem >> > @pci_bridge_pci 0000000000000000-00000000000fffff >> > 000001ff00000000-000001ff000fffff (prio 1, RW): alias >> > pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff >> > 000001ff000a0000-000001ff000affff (prio 2, RW): alias vga.chain4 >> > @vga.vram 0000000000000000-000000000000ffff >> > 000001ff000a0000-000001ff000bffff (prio 1, RW): vga-lowmem >> > 000001ff00800000-000001ff00ffffff (prio 1, RW): vga.vram >> > 000001ff01000000-000001ff0100ffff (prio 1, RW): vga.rom >> > 000001ff02000000-000001ff02ffffff (prio 1, RW): isa-mmio >> > 000001ff03000000-000001ff037fffff (prio 1, RW): isa-mmio >> > 000001fff0000000-000001fff03fffff (prio 0, R-): sun4u.prom >> > pci_bridge_pci >> > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci >> > pci_bridge_pci >> > 0000000000000000-7ffffffffffffffe (prio 0, RW): pci_bridge_pci >> > vga.vram >> > 0000000000800000-0000000000ffffff (prio 1, RW): vga.vram >> > I/O >> > 0000000000000000-000000000000ffff (prio 0, RW): io >> > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io >> > @pci_bridge_io 0000000000000000-0000000000000fff >> > 0000000000000000-0000000000000fff (prio 1, RW): alias pci_bridge_io >> > @pci_bridge_io 0000000000000000-0000000000000fff >> > 0000000000000060-0000000000000060 (prio 0, RW): i8042-data >> > 0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd >> > 0000000000000074-0000000000000077 (prio 0, RW): m48t59 >> > 00000000000001ce-00000000000001ce (prio 0, RW): vbe >> > 00000000000001d0-00000000000001d0 (prio 0, RW): vbe >> > 0000000000000378-000000000000037f (prio 0, RW): parallel >> > 00000000000003b4-00000000000003b5 (prio 0, RW): vga >> > 00000000000003ba-00000000000003ba (prio 0, RW): vga >> > 00000000000003c0-00000000000003cf (prio 0, RW): vga >> > 00000000000003d4-00000000000003d5 (prio 0, RW): vga >> > 00000000000003da-00000000000003da (prio 0, RW): vga >> > 00000000000003f1-00000000000003f5 (prio 0, RW): fdc >> > 00000000000003f7-00000000000003f7 (prio 0, RW): fdc >> > 00000000000003f8-00000000000003ff (prio 0, RW): serial >> > 0000000000000400-00000000000004ff (prio 1, RW): ne2000 >> > 0000000000000500-0000000000000507 (prio 1, RW): cmd646-data >> > 0000000000000510-0000000000000511 (prio 0, RW): fwcfg >> > 0000000000000580-0000000000000583 (prio 1, RW): cmd646-cmd >> > 0000000000000600-0000000000000607 (prio 1, RW): cmd646-data >> > 0000000000000680-0000000000000683 (prio 1, RW): cmd646-cmd >> > 0000000000000700-000000000000070f (prio 1, RW): cmd646-bmdma >> > 0000000000000700-0000000000000703 (prio 0, RW): cmd646-bmdma-bus >> > 0000000000000704-0000000000000707 (prio 0, RW): cmd646-bmdma-ioport >> > 0000000000000708-000000000000070b (prio 0, RW): cmd646-bmdma-bus >> > 000000000000070c-000000000000070f (prio 0, RW): cmd646-bmdma-ioport >> >> This looks better. >> >> > >> > Sill trying to understand what all this means. >> > >> > >> >> > hw/pci.c | 4 ++-- >> >> > 1 files changed, 2 insertions(+), 2 deletions(-) >> >> > >> >> > diff --git a/hw/pci.c b/hw/pci.c >> >> > index fee27fc..6d08cef 100644 >> >> > --- a/hw/pci.c >> >> > +++ b/hw/pci.c >> >> > @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) >> >> > memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); >> >> > >> >> > /* Supported memory and i/o types */ >> >> > - d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; >> >> > - d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; >> >> > + d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; >> >> > + d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; >> >> > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_BASE, >> >> > PCI_PREF_RANGE_TYPE_64); >> >> > pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_LIMIT, >> >> > -- >> >> > 1.7.9.111.gf3fb0
On Sun, Mar 04, 2012 at 01:38:38PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: > >> On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > >> >> > > >> >> > 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. > > > > Invalid read and address after block are also worrying. > > > > irqs are allocated with > > #define MAX_PILS 16 > > > > irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); > > > > then passed to apb: > > > > pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, > > &pci_bus3); > > > > which does: > > PCIBus *pci_apb_init(target_phys_addr_t special_base, > > target_phys_addr_t mem_base, > > qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) > > > > and > > > > for (i = 0; i < 32; i++) { > > sysbus_connect_irq(s, i, pic[i]); > > } > > Awful. But using 32 for MAX_PILS does not help either. Could you please clarify what is the SABRE device? Is it, in fact, a bridge device? Or not?
On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 01:38:38PM +0000, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin <mst@redhat.com> wrote: >> > On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: >> >> On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> >> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> >> >> >> > >> >> >> > 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. >> > >> > Invalid read and address after block are also worrying. >> > >> > irqs are allocated with >> > #define MAX_PILS 16 >> > >> > irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); >> > >> > then passed to apb: >> > >> > pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, >> > &pci_bus3); >> > >> > which does: >> > PCIBus *pci_apb_init(target_phys_addr_t special_base, >> > target_phys_addr_t mem_base, >> > qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) >> > >> > and >> > >> > for (i = 0; i < 32; i++) { >> > sysbus_connect_irq(s, i, pic[i]); >> > } >> >> Awful. But using 32 for MAX_PILS does not help either. > > > Could you please clarify what is the SABRE device? > Is it, in fact, a bridge device? Or not? Yes, it's the host bridge, also known as PBM. It's documented in UltraSPARC IIi User's Manual and there it says that the device is found in the configuration space. The secondary bridges are Simbas and should be called APBs. > > > -- > MST
On Sun, Mar 04, 2012 at 02:35:28PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Mar 04, 2012 at 01:38:38PM +0000, Blue Swirl wrote: > >> On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin <mst@redhat.com> wrote: > >> > On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: > >> >> On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > >> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > >> >> >> > > >> >> >> > 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. > >> > > >> > Invalid read and address after block are also worrying. > >> > > >> > irqs are allocated with > >> > #define MAX_PILS 16 > >> > > >> > irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); > >> > > >> > then passed to apb: > >> > > >> > pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, > >> > &pci_bus3); > >> > > >> > which does: > >> > PCIBus *pci_apb_init(target_phys_addr_t special_base, > >> > target_phys_addr_t mem_base, > >> > qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) > >> > > >> > and > >> > > >> > for (i = 0; i < 32; i++) { > >> > sysbus_connect_irq(s, i, pic[i]); > >> > } > >> > >> Awful. But using 32 for MAX_PILS does not help either. > > > > > > Could you please clarify what is the SABRE device? > > Is it, in fact, a bridge device? Or not? > > Yes, it's the host bridge, also known as PBM. It's documented in > UltraSPARC IIi User's Manual Btw would be nice to host the manuals at qemu.org our code points at sun.com URLs :( I am looking at 19.3.1 PCI Configuration Space and it appears to show that this is a regular device with a couple of custom registers at pffsets 0x40 and 0x41. Why do we want to pretend it is a bridge? > and there it says that the device is > found in the configuration space. > > The secondary bridges are Simbas and should be called APBs. As far as I can see from the code, it has header type NORMAL but sets is_bridge. This was done by this commit: 776e1bbb6cf4fe66a93c1a5dd814bbb650deca00 > > > > > > -- > > MST
On Sun, Mar 04, 2012 at 02:35:28PM +0000, Blue Swirl wrote: > Yes, it's the host bridge, also known as PBM. It's documented in > UltraSPARC IIi User's Manual and there it says that the device is > found in the configuration space. So it seems I can make things work if I disable is_bridge and make some bits in BAR4 writeable: pci_set_long(d->wmask + 0x20, 0xffff0000); I don't yet know why, and the manual says there should be no BARs. > The secondary bridges are Simbas and should be called APBs. > > > > > > > -- > > MST
On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 02:35:28PM +0000, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin <mst@redhat.com> wrote: >> > On Sun, Mar 04, 2012 at 01:38:38PM +0000, Blue Swirl wrote: >> >> On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin <mst@redhat.com> wrote: >> >> > On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: >> >> >> On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> >> >> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> >> >> >> >> > >> >> >> >> > 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. >> >> > >> >> > Invalid read and address after block are also worrying. >> >> > >> >> > irqs are allocated with >> >> > #define MAX_PILS 16 >> >> > >> >> > irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); >> >> > >> >> > then passed to apb: >> >> > >> >> > pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, >> >> > &pci_bus3); >> >> > >> >> > which does: >> >> > PCIBus *pci_apb_init(target_phys_addr_t special_base, >> >> > target_phys_addr_t mem_base, >> >> > qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) >> >> > >> >> > and >> >> > >> >> > for (i = 0; i < 32; i++) { >> >> > sysbus_connect_irq(s, i, pic[i]); >> >> > } >> >> >> >> Awful. But using 32 for MAX_PILS does not help either. >> > >> > >> > Could you please clarify what is the SABRE device? >> > Is it, in fact, a bridge device? Or not? >> >> Yes, it's the host bridge, also known as PBM. It's documented in >> UltraSPARC IIi User's Manual > > Btw would be nice to host the manuals at qemu.org > our code points at sun.com URLs :( I have most if not all manuals, downloaded from sun.com, but I'm not sure if they can be redistributed. > I am looking at 19.3.1 PCI Configuration Space > and it appears to show that this is a regular device > with a couple of custom registers at pffsets 0x40 > and 0x41. > > Why do we want to pretend it is a bridge? It's the host bridge and the device class is PCI_CLASS_BRIDGE_HOST. > >> and there it says that the device is >> found in the configuration space. >> >> The secondary bridges are Simbas and should be called APBs. > > As far as I can see from the code, it has header type > NORMAL but sets is_bridge. > This was done by this commit: > 776e1bbb6cf4fe66a93c1a5dd814bbb650deca00 IIRC otherwise some registers are not writable. > >> > >> > >> > -- >> > MST
On Sun, Mar 04, 2012 at 05:07:34PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 15:22, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Mar 04, 2012 at 02:35:28PM +0000, Blue Swirl wrote: > >> On Sun, Mar 4, 2012 at 14:23, Michael S. Tsirkin <mst@redhat.com> wrote: > >> > On Sun, Mar 04, 2012 at 01:38:38PM +0000, Blue Swirl wrote: > >> >> On Sun, Mar 4, 2012 at 13:28, Michael S. Tsirkin <mst@redhat.com> wrote: > >> >> > On Sun, Mar 04, 2012 at 12:37:57PM +0000, Blue Swirl wrote: > >> >> >> On Sun, Mar 4, 2012 at 12:21, Michael S. Tsirkin <mst@redhat.com> 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 <mst@redhat.com> 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 <mark.cave-ayland@ilande.co.uk> > >> >> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > >> >> >> >> > > >> >> >> >> > 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. > >> >> > > >> >> > Invalid read and address after block are also worrying. > >> >> > > >> >> > irqs are allocated with > >> >> > #define MAX_PILS 16 > >> >> > > >> >> > irq = qemu_allocate_irqs(cpu_set_irq, env, MAX_PILS); > >> >> > > >> >> > then passed to apb: > >> >> > > >> >> > pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, irq, &pci_bus2, > >> >> > &pci_bus3); > >> >> > > >> >> > which does: > >> >> > PCIBus *pci_apb_init(target_phys_addr_t special_base, > >> >> > target_phys_addr_t mem_base, > >> >> > qemu_irq *pic, PCIBus **bus2, PCIBus **bus3) > >> >> > > >> >> > and > >> >> > > >> >> > for (i = 0; i < 32; i++) { > >> >> > sysbus_connect_irq(s, i, pic[i]); > >> >> > } > >> >> > >> >> Awful. But using 32 for MAX_PILS does not help either. > >> > > >> > > >> > Could you please clarify what is the SABRE device? > >> > Is it, in fact, a bridge device? Or not? > >> > >> Yes, it's the host bridge, also known as PBM. It's documented in > >> UltraSPARC IIi User's Manual > > > > Btw would be nice to host the manuals at qemu.org > > our code points at sun.com URLs :( > > I have most if not all manuals, downloaded from sun.com, but I'm not > sure if they can be redistributed. Okay ... Let's change the link to point to some other place which has them? > > I am looking at 19.3.1 PCI Configuration Space > > and it appears to show that this is a regular device > > with a couple of custom registers at pffsets 0x40 > > and 0x41. > > > > Why do we want to pretend it is a bridge? > > It's the host bridge and the device class is PCI_CLASS_BRIDGE_HOST. Yes. But the *header* type is 0 (NORMAL) while the code in pci_init_mask_bridge which is the only user of the is_bridge register initializes a type 1 (BRIDGE) header. So it just happens to do a vaguely correct thing. > > > >> and there it says that the device is > >> found in the configuration space. > >> > >> The secondary bridges are Simbas and should be called APBs. > > > > As far as I can see from the code, it has header type > > NORMAL but sets is_bridge. > > This was done by this commit: > > 776e1bbb6cf4fe66a93c1a5dd814bbb650deca00 > > IIRC otherwise some registers are not writable. Yes but which ones? I looked at the manual and it does not list any registers. Playing with code, it looks like we just need to make *some* BAR writeable. I tried with pci_set_long(d->wmask + PCI_BASE_ADDRESS_0, 0xfffffff0); to pci_set_long(d->wmask + PCI_BASE_ADDRESS_5, 0xfffffff0); and any one of these makes bios get at least to the prompt. > > > >> > > >> > > >> > -- > >> > MST
diff --git a/hw/pci.c b/hw/pci.c index fee27fc..6d08cef 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -633,8 +633,8 @@ static void pci_init_mask_bridge(PCIDevice *d) memset(d->wmask + PCI_PREF_BASE_UPPER32, 0xff, 8); /* Supported memory and i/o types */ - d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_32; - d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_32; + d->config[PCI_IO_BASE] |= PCI_IO_RANGE_TYPE_16; + d->config[PCI_IO_LIMIT] |= PCI_IO_RANGE_TYPE_16; pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_BASE, PCI_PREF_RANGE_TYPE_64); pci_word_test_and_set_mask(d->config + PCI_PREF_MEMORY_LIMIT,
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 <mark.cave-ayland@ilande.co.uk> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Mark, can you confirm that this fixes the bug for you? --- hw/pci.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)