* [Qemu-devel] [PATCH] pci: fix bridge IO/BASE @ 2012-03-04 9:46 Michael S. Tsirkin 2012-03-04 10:27 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 9:46 UTC (permalink / raw) To: qemu-devel, Blue Swirl, Anthony Liguori, Mark Cave-Ayland Cc: Michael S. Tsirkin 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(-) 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 ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 9:46 [Qemu-devel] [PATCH] pci: fix bridge IO/BASE Michael S. Tsirkin @ 2012-03-04 10:27 ` Blue Swirl 2012-03-04 12:21 ` Michael S. Tsirkin ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Blue Swirl @ 2012-03-04 10:27 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 10:27 ` Blue Swirl @ 2012-03-04 12:21 ` Michael S. Tsirkin 2012-03-04 12:37 ` Blue Swirl 2012-03-04 12:28 ` Avi Kivity 2012-03-04 12:33 ` Michael S. Tsirkin 2 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 12:21 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:21 ` Michael S. Tsirkin @ 2012-03-04 12:37 ` Blue Swirl 2012-03-04 13:28 ` Michael S. Tsirkin 2012-03-04 13:38 ` Michael S. Tsirkin 0 siblings, 2 replies; 41+ messages in thread From: Blue Swirl @ 2012-03-04 12:37 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:37 ` Blue Swirl @ 2012-03-04 13:28 ` Michael S. Tsirkin 2012-03-04 13:38 ` Blue Swirl 2012-03-04 13:38 ` Michael S. Tsirkin 1 sibling, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 13:28 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 13:28 ` Michael S. Tsirkin @ 2012-03-04 13:38 ` Blue Swirl 2012-03-04 14:23 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 13:38 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 13:38 ` Blue Swirl @ 2012-03-04 14:23 ` Michael S. Tsirkin 2012-03-04 14:35 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 14:23 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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? -- MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 14:23 ` Michael S. Tsirkin @ 2012-03-04 14:35 ` Blue Swirl 2012-03-04 15:22 ` Michael S. Tsirkin 2012-03-04 15:41 ` Michael S. Tsirkin 0 siblings, 2 replies; 41+ messages in thread From: Blue Swirl @ 2012-03-04 14:35 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 14:35 ` Blue Swirl @ 2012-03-04 15:22 ` Michael S. Tsirkin 2012-03-04 17:07 ` Blue Swirl 2012-03-04 15:41 ` Michael S. Tsirkin 1 sibling, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 15:22 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 15:22 ` Michael S. Tsirkin @ 2012-03-04 17:07 ` Blue Swirl 2012-03-04 17:35 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 17:07 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 17:07 ` Blue Swirl @ 2012-03-04 17:35 ` Michael S. Tsirkin 2012-03-04 19:51 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 17:35 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 17:35 ` Michael S. Tsirkin @ 2012-03-04 19:51 ` Blue Swirl 2012-03-04 20:02 ` Michael S. Tsirkin 2012-03-04 21:56 ` Mark Cave-Ayland 0 siblings, 2 replies; 41+ messages in thread From: Blue Swirl @ 2012-03-04 19:51 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori [-- Attachment #1: Type: text/plain, Size: 9294 bytes --] On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin <mst@redhat.com> wrote: > 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. Well, that is still according to device spec. >> > >> >> 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. I now know the root cause of the problem. OpenBIOS programs the BARs somewhat correctly just by accident. The initial io_base and mem_base for BARs are not correct, but because the host bridge BARs (and also 6 of which 4 are not even BARs!) are programmed first, the bases happened to settle to values that happen to work. The commit revealed the problem since the settling didn't happen. The mask changes just let the host bridge setup continue to do the magic. By just changing OpenBIOS (see attached patch), I can get the devices to work (assuming that VGA is a separate problem). There's no need to change QEMU. >> > >> >> > >> >> > >> >> > -- >> >> > MST [-- Attachment #2: 0001-pci-fix-BAR-setup.patch --] [-- Type: text/x-patch, Size: 8701 bytes --] From 3f957e2dc8477f00f6d3a9491d81399ee750c725 Mon Sep 17 00:00:00 2001 Message-Id: <3f957e2dc8477f00f6d3a9491d81399ee750c725.1330890410.git.blauwirbel@gmail.com> From: Blue Swirl <blauwirbel@gmail.com> Date: Sun, 4 Mar 2012 19:46:38 +0000 Subject: [PATCH] pci: fix BAR setup A change in QEMU on how PCI bridges are setup revealed a bug in OpenBIOS PCI setup. On Sparc64, the BARs just happened to get somewhat correct values by accident before the commit but not after the change. Avoid to set up BARs for host bridge. Fix bridge check, this lead to setting up 6 BARs instead of more correct 2. If a bridge doesn't have any devices behind it, disable it entirely. Fix Sparc64 PCI memory base. Signed-off-by: Blue Swirl <blauwirbel@gmail.com> --- arch/sparc64/openbios.c | 2 +- drivers/pci.c | 67 ++++++++++++++++++++++++++++++++++------------ drivers/pci.h | 7 +++++ 3 files changed, 57 insertions(+), 19 deletions(-) diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index ac709fe..a1544a8 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { .cfg_base = APB_SPECIAL_BASE, .cfg_len = 0x2000000, .host_mem_base = APB_MEM_BASE, - .pci_mem_base = 0, + .pci_mem_base = 0x10000000, .mem_len = 0x10000000, .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space .io_len = 0x10000, diff --git a/drivers/pci.c b/drivers/pci.c index f8c6414..6ed0c03 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -966,11 +966,18 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, size = min_align; reloc = (reloc + size -1) & ~(size - 1); if (*io_base == base) { + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", + *io_base, reloc + size); *io_base = reloc + size; reloc -= arch->io_base; } else { + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", + *mem_base, reloc + size); *mem_base = reloc + size; } + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " + "io_base 0x%lx mem_base 0x%lx\n", + config->path, reloc, *p_omask, *io_base, *mem_base); pci_config_write32(addr, config_addr, reloc | *p_omask); config->assigned[reg] = reloc | *p_omask; } @@ -1021,26 +1028,30 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, pci_config_write16(addr, PCI_COMMAND, cmd); } -static void ob_configure_pci_device(const char* parent_path, - int *bus_num, unsigned long *mem_base, unsigned long *io_base, - int bus, int devnum, int fn, int *p_is_multi); +static int ob_configure_pci_device(const char* parent_path, + int *bus_num, unsigned long *mem_base, + unsigned long *io_base, int bus, int devnum, + int fn, int *p_is_multi); -static void ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, - unsigned long *io_base, const char *path, - int bus) +static int ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, + unsigned long *io_base, const char *path, + int bus) { - int devnum, fn, is_multi; + int devnum, fn, is_multi, ndevices = 0; PCI_DPRINTF("\nScanning bus %d at %s...\n", bus, path); for (devnum = 0; devnum < 32; devnum++) { is_multi = 0; for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { - ob_configure_pci_device(path, bus_num, mem_base, io_base, - bus, devnum, fn, &is_multi); + ndevices += ob_configure_pci_device(path, bus_num, + mem_base, io_base, + bus, devnum, fn, + &is_multi); } } + return ndevices; } static void ob_configure_pci_bridge(pci_addr addr, @@ -1048,6 +1059,9 @@ static void ob_configure_pci_bridge(pci_addr addr, unsigned long *io_base, int primary_bus, pci_config_t *config) { + int ndevices; + uint8_t command; + config->primary_bus = primary_bus; pci_config_write8(addr, PCI_PRIMARY_BUS, config->primary_bus); @@ -1062,16 +1076,30 @@ static void ob_configure_pci_bridge(pci_addr addr, /* make pci bridge parent device, prepare for recursion */ - ob_scan_pci_bus(bus_num, mem_base, io_base, - config->path, config->secondary_bus); + ndevices = ob_scan_pci_bus(bus_num, mem_base, io_base, + config->path, config->secondary_bus); + if (!ndevices) { + /* no devices, disable bridging */ + PCI_DPRINTF("disabling bridge %s\n", config->path); + command = pci_config_read8(addr, PCI_COMMAND); + command &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | + PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_MASTER); + pci_config_write8(addr, PCI_COMMAND, command); + pci_config_write8(addr, PCI_IO_BASE, 0); + pci_config_write8(addr, PCI_IO_LIMIT, 0); + pci_config_write8(addr, PCI_MEMORY_BASE, 0); + pci_config_write8(addr, PCI_MEMORY_LIMIT, 0); + return; + } /* bus scan updates *bus_num to last revealed pci bus number */ config->subordinate_bus = *bus_num; pci_config_write8(addr, PCI_SUBORDINATE_BUS, config->subordinate_bus); - PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d\n", - config->path, config->primary_bus, config->secondary_bus, - config->subordinate_bus); + PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d" + " ndev=%d\n", + config->path, config->primary_bus, config->secondary_bus, + config->subordinate_bus, ndevices); pci_set_bus_range(config); } @@ -1117,7 +1145,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, return 1; } -static void ob_configure_pci_device(const char* parent_path, +static int ob_configure_pci_device(const char* parent_path, int *bus_num, unsigned long *mem_base, unsigned long *io_base, int bus, int devnum, int fn, int *p_is_multi) { @@ -1133,7 +1161,7 @@ static void ob_configure_pci_device(const char* parent_path, int is_host_bridge = 0; if (!ob_pci_read_identification(bus, devnum, fn, &vid, &did, &class, &subclass)) { - return; + return 0; } addr = PCI_ADDR(bus, devnum, fn); @@ -1195,16 +1223,18 @@ static void ob_configure_pci_device(const char* parent_path, if (get_property(phandle, "vendor-id", NULL)) { PCI_DPRINTF("host bridge already configured\n"); - return; + return 0; } } activate_dev(phandle); - if (htype & PCI_HEADER_TYPE_BRIDGE) { + if (htype & PCI_HEADER_TYPE_BRIDGE || (class == PCI_BASE_CLASS_BRIDGE)) { + PCI_DPRINTF("Bridge 2 bars, htype %x\n", htype); num_bars = 2; rom_bar = PCI_ROM_ADDRESS1; } else { + PCI_DPRINTF("Device 6 bars, htype %x\n", htype); num_bars = 6; rom_bar = PCI_ROM_ADDRESS; } @@ -1240,6 +1270,7 @@ static void ob_configure_pci_device(const char* parent_path, ob_configure_pci_bridge(addr, bus_num, mem_base, io_base, bus, &config); } + return 1; } int ob_pci_init(void) diff --git a/drivers/pci.h b/drivers/pci.h index 0f6ae1f..4314507 100644 --- a/drivers/pci.h +++ b/drivers/pci.h @@ -7,6 +7,8 @@ #define PCI_COMMAND 0x04 #define PCI_COMMAND_IO 0x01 #define PCI_COMMAND_MEMORY 0x02 +#define PCI_COMMAND_MASTER 0x4 /* Enable bus mastering */ +#define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */ #define PCI_STATUS 0x06 /* 16 bits */ #define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ @@ -44,6 +46,11 @@ #define PCI_BASE_ADDR_4 0x20 #define PCI_BASE_ADDR_5 0x24 +#define PCI_IO_BASE 0x1c /* I/O range behind the bridge */ +#define PCI_IO_LIMIT 0x1d +#define PCI_MEMORY_BASE 0x20 /* Memory range behind */ +#define PCI_MEMORY_LIMIT 0x22 + #define PCI_SUBSYSTEM_VENDOR_ID 0x2c #define PCI_SUBSYSTEM_ID 0x2e -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 19:51 ` Blue Swirl @ 2012-03-04 20:02 ` Michael S. Tsirkin 2012-03-04 20:32 ` Blue Swirl 2012-03-04 21:56 ` Mark Cave-Ayland 1 sibling, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 20:02 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Sun, Mar 04, 2012 at 07:51:02PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin <mst@redhat.com> wrote: > > 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. > > Well, that is still according to device spec. I tried to find anything in the spec that says any register after 0x10 is implemented but failed. Can you tell me which chater and what it says? > >> > > >> >> 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. > > I now know the root cause of the problem. OpenBIOS programs the BARs > somewhat correctly just by accident. The initial io_base and mem_base > for BARs are not correct, but because the host bridge BARs (and also 6 > of which 4 are not even BARs!) are programmed first, the bases > happened to settle to values that happen to work. The commit revealed > the problem since the settling didn't happen. The mask changes just > let the host bridge setup continue to do the magic. > > By just changing OpenBIOS (see attached patch), I can get the devices > to work (assuming that VGA is a separate problem). There's no need to > change QEMU. > > >> > > >> >> > > >> >> > > >> >> > -- > >> >> > MST > From 3f957e2dc8477f00f6d3a9491d81399ee750c725 Mon Sep 17 00:00:00 2001 > Message-Id: <3f957e2dc8477f00f6d3a9491d81399ee750c725.1330890410.git.blauwirbel@gmail.com> > From: Blue Swirl <blauwirbel@gmail.com> > Date: Sun, 4 Mar 2012 19:46:38 +0000 > Subject: [PATCH] pci: fix BAR setup > > A change in QEMU on how PCI bridges are setup revealed > a bug in OpenBIOS PCI setup. On Sparc64, the BARs just > happened to get somewhat correct values by accident before > the commit but not after the change. > > Avoid to set up BARs for host bridge. Fix bridge > check, this lead to setting up 6 BARs instead of more > correct 2. If a bridge doesn't have any devices behind it, > disable it entirely. Fix Sparc64 PCI memory base. > > Signed-off-by: Blue Swirl <blauwirbel@gmail.com> > --- > arch/sparc64/openbios.c | 2 +- > drivers/pci.c | 67 ++++++++++++++++++++++++++++++++++------------ > drivers/pci.h | 7 +++++ > 3 files changed, 57 insertions(+), 19 deletions(-) > > diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c > index ac709fe..a1544a8 100644 > --- a/arch/sparc64/openbios.c > +++ b/arch/sparc64/openbios.c > @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { > .cfg_base = APB_SPECIAL_BASE, > .cfg_len = 0x2000000, > .host_mem_base = APB_MEM_BASE, > - .pci_mem_base = 0, > + .pci_mem_base = 0x10000000, > .mem_len = 0x10000000, > .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space > .io_len = 0x10000, > diff --git a/drivers/pci.c b/drivers/pci.c > index f8c6414..6ed0c03 100644 > --- a/drivers/pci.c > +++ b/drivers/pci.c > @@ -966,11 +966,18 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, > size = min_align; > reloc = (reloc + size -1) & ~(size - 1); > if (*io_base == base) { > + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", > + *io_base, reloc + size); > *io_base = reloc + size; > reloc -= arch->io_base; > } else { > + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", > + *mem_base, reloc + size); > *mem_base = reloc + size; > } > + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " > + "io_base 0x%lx mem_base 0x%lx\n", > + config->path, reloc, *p_omask, *io_base, *mem_base); > pci_config_write32(addr, config_addr, reloc | *p_omask); > config->assigned[reg] = reloc | *p_omask; > } > @@ -1021,26 +1028,30 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, > pci_config_write16(addr, PCI_COMMAND, cmd); > } > > -static void ob_configure_pci_device(const char* parent_path, > - int *bus_num, unsigned long *mem_base, unsigned long *io_base, > - int bus, int devnum, int fn, int *p_is_multi); > +static int ob_configure_pci_device(const char* parent_path, > + int *bus_num, unsigned long *mem_base, > + unsigned long *io_base, int bus, int devnum, > + int fn, int *p_is_multi); > > -static void ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, > - unsigned long *io_base, const char *path, > - int bus) > +static int ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, > + unsigned long *io_base, const char *path, > + int bus) > { > - int devnum, fn, is_multi; > + int devnum, fn, is_multi, ndevices = 0; > > PCI_DPRINTF("\nScanning bus %d at %s...\n", bus, path); > > for (devnum = 0; devnum < 32; devnum++) { > is_multi = 0; > for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { > - ob_configure_pci_device(path, bus_num, mem_base, io_base, > - bus, devnum, fn, &is_multi); > + ndevices += ob_configure_pci_device(path, bus_num, > + mem_base, io_base, > + bus, devnum, fn, > + &is_multi); > > } > } > + return ndevices; > } > > static void ob_configure_pci_bridge(pci_addr addr, > @@ -1048,6 +1059,9 @@ static void ob_configure_pci_bridge(pci_addr addr, > unsigned long *io_base, > int primary_bus, pci_config_t *config) > { > + int ndevices; > + uint8_t command; > + > config->primary_bus = primary_bus; > pci_config_write8(addr, PCI_PRIMARY_BUS, config->primary_bus); > > @@ -1062,16 +1076,30 @@ static void ob_configure_pci_bridge(pci_addr addr, > > /* make pci bridge parent device, prepare for recursion */ > > - ob_scan_pci_bus(bus_num, mem_base, io_base, > - config->path, config->secondary_bus); > + ndevices = ob_scan_pci_bus(bus_num, mem_base, io_base, > + config->path, config->secondary_bus); > + if (!ndevices) { > + /* no devices, disable bridging */ > + PCI_DPRINTF("disabling bridge %s\n", config->path); > + command = pci_config_read8(addr, PCI_COMMAND); > + command &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | > + PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_MASTER); > + pci_config_write8(addr, PCI_COMMAND, command); > + pci_config_write8(addr, PCI_IO_BASE, 0); > + pci_config_write8(addr, PCI_IO_LIMIT, 0); > + pci_config_write8(addr, PCI_MEMORY_BASE, 0); > + pci_config_write8(addr, PCI_MEMORY_LIMIT, 0); > + return; > + } > > /* bus scan updates *bus_num to last revealed pci bus number */ > config->subordinate_bus = *bus_num; > pci_config_write8(addr, PCI_SUBORDINATE_BUS, config->subordinate_bus); > > - PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d\n", > - config->path, config->primary_bus, config->secondary_bus, > - config->subordinate_bus); > + PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d" > + " ndev=%d\n", > + config->path, config->primary_bus, config->secondary_bus, > + config->subordinate_bus, ndevices); > > pci_set_bus_range(config); > } > @@ -1117,7 +1145,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, > return 1; > } > > -static void ob_configure_pci_device(const char* parent_path, > +static int ob_configure_pci_device(const char* parent_path, > int *bus_num, unsigned long *mem_base, unsigned long *io_base, > int bus, int devnum, int fn, int *p_is_multi) > { > @@ -1133,7 +1161,7 @@ static void ob_configure_pci_device(const char* parent_path, > int is_host_bridge = 0; > > if (!ob_pci_read_identification(bus, devnum, fn, &vid, &did, &class, &subclass)) { > - return; > + return 0; > } > > addr = PCI_ADDR(bus, devnum, fn); > @@ -1195,16 +1223,18 @@ static void ob_configure_pci_device(const char* parent_path, > > if (get_property(phandle, "vendor-id", NULL)) { > PCI_DPRINTF("host bridge already configured\n"); > - return; > + return 0; > } > } > > activate_dev(phandle); > > - if (htype & PCI_HEADER_TYPE_BRIDGE) { > + if (htype & PCI_HEADER_TYPE_BRIDGE || (class == PCI_BASE_CLASS_BRIDGE)) { > + PCI_DPRINTF("Bridge 2 bars, htype %x\n", htype); > num_bars = 2; > rom_bar = PCI_ROM_ADDRESS1; > } else { > + PCI_DPRINTF("Device 6 bars, htype %x\n", htype); > num_bars = 6; > rom_bar = PCI_ROM_ADDRESS; > } > @@ -1240,6 +1270,7 @@ static void ob_configure_pci_device(const char* parent_path, > > ob_configure_pci_bridge(addr, bus_num, mem_base, io_base, bus, &config); > } > + return 1; > } > > int ob_pci_init(void) > diff --git a/drivers/pci.h b/drivers/pci.h > index 0f6ae1f..4314507 100644 > --- a/drivers/pci.h > +++ b/drivers/pci.h > @@ -7,6 +7,8 @@ > #define PCI_COMMAND 0x04 > #define PCI_COMMAND_IO 0x01 > #define PCI_COMMAND_MEMORY 0x02 > +#define PCI_COMMAND_MASTER 0x4 /* Enable bus mastering */ > +#define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */ > > #define PCI_STATUS 0x06 /* 16 bits */ > #define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ > @@ -44,6 +46,11 @@ > #define PCI_BASE_ADDR_4 0x20 > #define PCI_BASE_ADDR_5 0x24 > > +#define PCI_IO_BASE 0x1c /* I/O range behind the bridge */ > +#define PCI_IO_LIMIT 0x1d > +#define PCI_MEMORY_BASE 0x20 /* Memory range behind */ > +#define PCI_MEMORY_LIMIT 0x22 > + > #define PCI_SUBSYSTEM_VENDOR_ID 0x2c > #define PCI_SUBSYSTEM_ID 0x2e > > -- > 1.7.2.5 > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 20:02 ` Michael S. Tsirkin @ 2012-03-04 20:32 ` Blue Swirl 2012-03-04 21:28 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 20:32 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Sun, Mar 4, 2012 at 20:02, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 07:51:02PM +0000, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin <mst@redhat.com> wrote: >> > 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. >> >> Well, that is still according to device spec. > > I tried to find anything in the spec that says any register > after 0x10 is implemented but failed. > Can you tell me which chater and what it says? 19.3.1.10 tells that the header type is 0, as you noted too. Still, the register layout matches bridge spec instead, for example there are bus number registers in place of BAR 2. This conflicts with bridge spec 3.2.4.9. Maybe the device predates the specification. >> >> > >> >> >> 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. >> >> I now know the root cause of the problem. OpenBIOS programs the BARs >> somewhat correctly just by accident. The initial io_base and mem_base >> for BARs are not correct, but because the host bridge BARs (and also 6 >> of which 4 are not even BARs!) are programmed first, the bases >> happened to settle to values that happen to work. The commit revealed >> the problem since the settling didn't happen. The mask changes just >> let the host bridge setup continue to do the magic. >> >> By just changing OpenBIOS (see attached patch), I can get the devices >> to work (assuming that VGA is a separate problem). There's no need to >> change QEMU. >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > MST > >> From 3f957e2dc8477f00f6d3a9491d81399ee750c725 Mon Sep 17 00:00:00 2001 >> Message-Id: <3f957e2dc8477f00f6d3a9491d81399ee750c725.1330890410.git.blauwirbel@gmail.com> >> From: Blue Swirl <blauwirbel@gmail.com> >> Date: Sun, 4 Mar 2012 19:46:38 +0000 >> Subject: [PATCH] pci: fix BAR setup >> >> A change in QEMU on how PCI bridges are setup revealed >> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >> happened to get somewhat correct values by accident before >> the commit but not after the change. >> >> Avoid to set up BARs for host bridge. Fix bridge >> check, this lead to setting up 6 BARs instead of more >> correct 2. If a bridge doesn't have any devices behind it, >> disable it entirely. Fix Sparc64 PCI memory base. >> >> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> >> --- >> arch/sparc64/openbios.c | 2 +- >> drivers/pci.c | 67 ++++++++++++++++++++++++++++++++++------------ >> drivers/pci.h | 7 +++++ >> 3 files changed, 57 insertions(+), 19 deletions(-) >> >> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >> index ac709fe..a1544a8 100644 >> --- a/arch/sparc64/openbios.c >> +++ b/arch/sparc64/openbios.c >> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >> .cfg_base = APB_SPECIAL_BASE, >> .cfg_len = 0x2000000, >> .host_mem_base = APB_MEM_BASE, >> - .pci_mem_base = 0, >> + .pci_mem_base = 0x10000000, >> .mem_len = 0x10000000, >> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >> .io_len = 0x10000, >> diff --git a/drivers/pci.c b/drivers/pci.c >> index f8c6414..6ed0c03 100644 >> --- a/drivers/pci.c >> +++ b/drivers/pci.c >> @@ -966,11 +966,18 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, >> size = min_align; >> reloc = (reloc + size -1) & ~(size - 1); >> if (*io_base == base) { >> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >> + *io_base, reloc + size); >> *io_base = reloc + size; >> reloc -= arch->io_base; >> } else { >> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >> + *mem_base, reloc + size); >> *mem_base = reloc + size; >> } >> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >> + "io_base 0x%lx mem_base 0x%lx\n", >> + config->path, reloc, *p_omask, *io_base, *mem_base); >> pci_config_write32(addr, config_addr, reloc | *p_omask); >> config->assigned[reg] = reloc | *p_omask; >> } >> @@ -1021,26 +1028,30 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, >> pci_config_write16(addr, PCI_COMMAND, cmd); >> } >> >> -static void ob_configure_pci_device(const char* parent_path, >> - int *bus_num, unsigned long *mem_base, unsigned long *io_base, >> - int bus, int devnum, int fn, int *p_is_multi); >> +static int ob_configure_pci_device(const char* parent_path, >> + int *bus_num, unsigned long *mem_base, >> + unsigned long *io_base, int bus, int devnum, >> + int fn, int *p_is_multi); >> >> -static void ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, >> - unsigned long *io_base, const char *path, >> - int bus) >> +static int ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, >> + unsigned long *io_base, const char *path, >> + int bus) >> { >> - int devnum, fn, is_multi; >> + int devnum, fn, is_multi, ndevices = 0; >> >> PCI_DPRINTF("\nScanning bus %d at %s...\n", bus, path); >> >> for (devnum = 0; devnum < 32; devnum++) { >> is_multi = 0; >> for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { >> - ob_configure_pci_device(path, bus_num, mem_base, io_base, >> - bus, devnum, fn, &is_multi); >> + ndevices += ob_configure_pci_device(path, bus_num, >> + mem_base, io_base, >> + bus, devnum, fn, >> + &is_multi); >> >> } >> } >> + return ndevices; >> } >> >> static void ob_configure_pci_bridge(pci_addr addr, >> @@ -1048,6 +1059,9 @@ static void ob_configure_pci_bridge(pci_addr addr, >> unsigned long *io_base, >> int primary_bus, pci_config_t *config) >> { >> + int ndevices; >> + uint8_t command; >> + >> config->primary_bus = primary_bus; >> pci_config_write8(addr, PCI_PRIMARY_BUS, config->primary_bus); >> >> @@ -1062,16 +1076,30 @@ static void ob_configure_pci_bridge(pci_addr addr, >> >> /* make pci bridge parent device, prepare for recursion */ >> >> - ob_scan_pci_bus(bus_num, mem_base, io_base, >> - config->path, config->secondary_bus); >> + ndevices = ob_scan_pci_bus(bus_num, mem_base, io_base, >> + config->path, config->secondary_bus); >> + if (!ndevices) { >> + /* no devices, disable bridging */ >> + PCI_DPRINTF("disabling bridge %s\n", config->path); >> + command = pci_config_read8(addr, PCI_COMMAND); >> + command &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | >> + PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_MASTER); >> + pci_config_write8(addr, PCI_COMMAND, command); >> + pci_config_write8(addr, PCI_IO_BASE, 0); >> + pci_config_write8(addr, PCI_IO_LIMIT, 0); >> + pci_config_write8(addr, PCI_MEMORY_BASE, 0); >> + pci_config_write8(addr, PCI_MEMORY_LIMIT, 0); >> + return; >> + } >> >> /* bus scan updates *bus_num to last revealed pci bus number */ >> config->subordinate_bus = *bus_num; >> pci_config_write8(addr, PCI_SUBORDINATE_BUS, config->subordinate_bus); >> >> - PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d\n", >> - config->path, config->primary_bus, config->secondary_bus, >> - config->subordinate_bus); >> + PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d" >> + " ndev=%d\n", >> + config->path, config->primary_bus, config->secondary_bus, >> + config->subordinate_bus, ndevices); >> >> pci_set_bus_range(config); >> } >> @@ -1117,7 +1145,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, >> return 1; >> } >> >> -static void ob_configure_pci_device(const char* parent_path, >> +static int ob_configure_pci_device(const char* parent_path, >> int *bus_num, unsigned long *mem_base, unsigned long *io_base, >> int bus, int devnum, int fn, int *p_is_multi) >> { >> @@ -1133,7 +1161,7 @@ static void ob_configure_pci_device(const char* parent_path, >> int is_host_bridge = 0; >> >> if (!ob_pci_read_identification(bus, devnum, fn, &vid, &did, &class, &subclass)) { >> - return; >> + return 0; >> } >> >> addr = PCI_ADDR(bus, devnum, fn); >> @@ -1195,16 +1223,18 @@ static void ob_configure_pci_device(const char* parent_path, >> >> if (get_property(phandle, "vendor-id", NULL)) { >> PCI_DPRINTF("host bridge already configured\n"); >> - return; >> + return 0; >> } >> } >> >> activate_dev(phandle); >> >> - if (htype & PCI_HEADER_TYPE_BRIDGE) { >> + if (htype & PCI_HEADER_TYPE_BRIDGE || (class == PCI_BASE_CLASS_BRIDGE)) { >> + PCI_DPRINTF("Bridge 2 bars, htype %x\n", htype); >> num_bars = 2; >> rom_bar = PCI_ROM_ADDRESS1; >> } else { >> + PCI_DPRINTF("Device 6 bars, htype %x\n", htype); >> num_bars = 6; >> rom_bar = PCI_ROM_ADDRESS; >> } >> @@ -1240,6 +1270,7 @@ static void ob_configure_pci_device(const char* parent_path, >> >> ob_configure_pci_bridge(addr, bus_num, mem_base, io_base, bus, &config); >> } >> + return 1; >> } >> >> int ob_pci_init(void) >> diff --git a/drivers/pci.h b/drivers/pci.h >> index 0f6ae1f..4314507 100644 >> --- a/drivers/pci.h >> +++ b/drivers/pci.h >> @@ -7,6 +7,8 @@ >> #define PCI_COMMAND 0x04 >> #define PCI_COMMAND_IO 0x01 >> #define PCI_COMMAND_MEMORY 0x02 >> +#define PCI_COMMAND_MASTER 0x4 /* Enable bus mastering */ >> +#define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */ >> >> #define PCI_STATUS 0x06 /* 16 bits */ >> #define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ >> @@ -44,6 +46,11 @@ >> #define PCI_BASE_ADDR_4 0x20 >> #define PCI_BASE_ADDR_5 0x24 >> >> +#define PCI_IO_BASE 0x1c /* I/O range behind the bridge */ >> +#define PCI_IO_LIMIT 0x1d >> +#define PCI_MEMORY_BASE 0x20 /* Memory range behind */ >> +#define PCI_MEMORY_LIMIT 0x22 >> + >> #define PCI_SUBSYSTEM_VENDOR_ID 0x2c >> #define PCI_SUBSYSTEM_ID 0x2e >> >> -- >> 1.7.2.5 >> > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 20:32 ` Blue Swirl @ 2012-03-04 21:28 ` Michael S. Tsirkin 2012-03-04 21:54 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 21:28 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Sun, Mar 04, 2012 at 08:32:26PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 20:02, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Mar 04, 2012 at 07:51:02PM +0000, Blue Swirl wrote: > >> On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin <mst@redhat.com> wrote: > >> > 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. > >> > >> Well, that is still according to device spec. > > > > I tried to find anything in the spec that says any register > > after 0x10 is implemented but failed. > > Can you tell me which chater and what it says? > > 19.3.1.10 tells that the header type is 0, as you noted too. Still, > the register layout matches bridge spec instead, for example there are > bus number registers in place of BAR 2. Sorry I don't see this in 19.3.1 Where are these registers documented? In my spec all registers from 0x10 on are greyed out which it says above means 'not implemented'? My spec also says 'Base Address' for 0x10 - 0x27. I see bus number and subordinate bus number registers at 0x40 and 0x41, this is outside the configuration header. The spec also says they are unused. Are we looking at the same spec? Mine is copyright 1997. > This conflicts with bridge > spec 3.2.4.9. Maybe the device predates the specification. bridge spec 1.0 was released in 1994, 1.1 in 1998. This spec is from 1997, but the device might be older. > >> >> > > >> >> >> 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. > >> > >> I now know the root cause of the problem. OpenBIOS programs the BARs > >> somewhat correctly just by accident. The initial io_base and mem_base > >> for BARs are not correct, but because the host bridge BARs (and also 6 > >> of which 4 are not even BARs!) are programmed first, the bases > >> happened to settle to values that happen to work. The commit revealed > >> the problem since the settling didn't happen. The mask changes just > >> let the host bridge setup continue to do the magic. > >> > >> By just changing OpenBIOS (see attached patch), I can get the devices > >> to work (assuming that VGA is a separate problem). There's no need to > >> change QEMU. > >> > >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > MST > > > >> From 3f957e2dc8477f00f6d3a9491d81399ee750c725 Mon Sep 17 00:00:00 2001 > >> Message-Id: <3f957e2dc8477f00f6d3a9491d81399ee750c725.1330890410.git.blauwirbel@gmail.com> > >> From: Blue Swirl <blauwirbel@gmail.com> > >> Date: Sun, 4 Mar 2012 19:46:38 +0000 > >> Subject: [PATCH] pci: fix BAR setup > >> > >> A change in QEMU on how PCI bridges are setup revealed > >> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just > >> happened to get somewhat correct values by accident before > >> the commit but not after the change. > >> > >> Avoid to set up BARs for host bridge. Fix bridge > >> check, this lead to setting up 6 BARs instead of more > >> correct 2. If a bridge doesn't have any devices behind it, > >> disable it entirely. Fix Sparc64 PCI memory base. > >> > >> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> > >> --- > >> arch/sparc64/openbios.c | 2 +- > >> drivers/pci.c | 67 ++++++++++++++++++++++++++++++++++------------ > >> drivers/pci.h | 7 +++++ > >> 3 files changed, 57 insertions(+), 19 deletions(-) > >> > >> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c > >> index ac709fe..a1544a8 100644 > >> --- a/arch/sparc64/openbios.c > >> +++ b/arch/sparc64/openbios.c > >> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { > >> .cfg_base = APB_SPECIAL_BASE, > >> .cfg_len = 0x2000000, > >> .host_mem_base = APB_MEM_BASE, > >> - .pci_mem_base = 0, > >> + .pci_mem_base = 0x10000000, > >> .mem_len = 0x10000000, > >> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space > >> .io_len = 0x10000, > >> diff --git a/drivers/pci.c b/drivers/pci.c > >> index f8c6414..6ed0c03 100644 > >> --- a/drivers/pci.c > >> +++ b/drivers/pci.c > >> @@ -966,11 +966,18 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, > >> size = min_align; > >> reloc = (reloc + size -1) & ~(size - 1); > >> if (*io_base == base) { > >> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", > >> + *io_base, reloc + size); > >> *io_base = reloc + size; > >> reloc -= arch->io_base; > >> } else { > >> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", > >> + *mem_base, reloc + size); > >> *mem_base = reloc + size; > >> } > >> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " > >> + "io_base 0x%lx mem_base 0x%lx\n", > >> + config->path, reloc, *p_omask, *io_base, *mem_base); > >> pci_config_write32(addr, config_addr, reloc | *p_omask); > >> config->assigned[reg] = reloc | *p_omask; > >> } > >> @@ -1021,26 +1028,30 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, > >> pci_config_write16(addr, PCI_COMMAND, cmd); > >> } > >> > >> -static void ob_configure_pci_device(const char* parent_path, > >> - int *bus_num, unsigned long *mem_base, unsigned long *io_base, > >> - int bus, int devnum, int fn, int *p_is_multi); > >> +static int ob_configure_pci_device(const char* parent_path, > >> + int *bus_num, unsigned long *mem_base, > >> + unsigned long *io_base, int bus, int devnum, > >> + int fn, int *p_is_multi); > >> > >> -static void ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, > >> - unsigned long *io_base, const char *path, > >> - int bus) > >> +static int ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, > >> + unsigned long *io_base, const char *path, > >> + int bus) > >> { > >> - int devnum, fn, is_multi; > >> + int devnum, fn, is_multi, ndevices = 0; > >> > >> PCI_DPRINTF("\nScanning bus %d at %s...\n", bus, path); > >> > >> for (devnum = 0; devnum < 32; devnum++) { > >> is_multi = 0; > >> for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { > >> - ob_configure_pci_device(path, bus_num, mem_base, io_base, > >> - bus, devnum, fn, &is_multi); > >> + ndevices += ob_configure_pci_device(path, bus_num, > >> + mem_base, io_base, > >> + bus, devnum, fn, > >> + &is_multi); > >> > >> } > >> } > >> + return ndevices; > >> } > >> > >> static void ob_configure_pci_bridge(pci_addr addr, > >> @@ -1048,6 +1059,9 @@ static void ob_configure_pci_bridge(pci_addr addr, > >> unsigned long *io_base, > >> int primary_bus, pci_config_t *config) > >> { > >> + int ndevices; > >> + uint8_t command; > >> + > >> config->primary_bus = primary_bus; > >> pci_config_write8(addr, PCI_PRIMARY_BUS, config->primary_bus); > >> > >> @@ -1062,16 +1076,30 @@ static void ob_configure_pci_bridge(pci_addr addr, > >> > >> /* make pci bridge parent device, prepare for recursion */ > >> > >> - ob_scan_pci_bus(bus_num, mem_base, io_base, > >> - config->path, config->secondary_bus); > >> + ndevices = ob_scan_pci_bus(bus_num, mem_base, io_base, > >> + config->path, config->secondary_bus); > >> + if (!ndevices) { > >> + /* no devices, disable bridging */ > >> + PCI_DPRINTF("disabling bridge %s\n", config->path); > >> + command = pci_config_read8(addr, PCI_COMMAND); > >> + command &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | > >> + PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_MASTER); > >> + pci_config_write8(addr, PCI_COMMAND, command); > >> + pci_config_write8(addr, PCI_IO_BASE, 0); > >> + pci_config_write8(addr, PCI_IO_LIMIT, 0); > >> + pci_config_write8(addr, PCI_MEMORY_BASE, 0); > >> + pci_config_write8(addr, PCI_MEMORY_LIMIT, 0); > >> + return; > >> + } > >> > >> /* bus scan updates *bus_num to last revealed pci bus number */ > >> config->subordinate_bus = *bus_num; > >> pci_config_write8(addr, PCI_SUBORDINATE_BUS, config->subordinate_bus); > >> > >> - PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d\n", > >> - config->path, config->primary_bus, config->secondary_bus, > >> - config->subordinate_bus); > >> + PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d" > >> + " ndev=%d\n", > >> + config->path, config->primary_bus, config->secondary_bus, > >> + config->subordinate_bus, ndevices); > >> > >> pci_set_bus_range(config); > >> } > >> @@ -1117,7 +1145,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, > >> return 1; > >> } > >> > >> -static void ob_configure_pci_device(const char* parent_path, > >> +static int ob_configure_pci_device(const char* parent_path, > >> int *bus_num, unsigned long *mem_base, unsigned long *io_base, > >> int bus, int devnum, int fn, int *p_is_multi) > >> { > >> @@ -1133,7 +1161,7 @@ static void ob_configure_pci_device(const char* parent_path, > >> int is_host_bridge = 0; > >> > >> if (!ob_pci_read_identification(bus, devnum, fn, &vid, &did, &class, &subclass)) { > >> - return; > >> + return 0; > >> } > >> > >> addr = PCI_ADDR(bus, devnum, fn); > >> @@ -1195,16 +1223,18 @@ static void ob_configure_pci_device(const char* parent_path, > >> > >> if (get_property(phandle, "vendor-id", NULL)) { > >> PCI_DPRINTF("host bridge already configured\n"); > >> - return; > >> + return 0; > >> } > >> } > >> > >> activate_dev(phandle); > >> > >> - if (htype & PCI_HEADER_TYPE_BRIDGE) { > >> + if (htype & PCI_HEADER_TYPE_BRIDGE || (class == PCI_BASE_CLASS_BRIDGE)) { > >> + PCI_DPRINTF("Bridge 2 bars, htype %x\n", htype); > >> num_bars = 2; > >> rom_bar = PCI_ROM_ADDRESS1; > >> } else { > >> + PCI_DPRINTF("Device 6 bars, htype %x\n", htype); > >> num_bars = 6; > >> rom_bar = PCI_ROM_ADDRESS; > >> } > >> @@ -1240,6 +1270,7 @@ static void ob_configure_pci_device(const char* parent_path, > >> > >> ob_configure_pci_bridge(addr, bus_num, mem_base, io_base, bus, &config); > >> } > >> + return 1; > >> } > >> > >> int ob_pci_init(void) > >> diff --git a/drivers/pci.h b/drivers/pci.h > >> index 0f6ae1f..4314507 100644 > >> --- a/drivers/pci.h > >> +++ b/drivers/pci.h > >> @@ -7,6 +7,8 @@ > >> #define PCI_COMMAND 0x04 > >> #define PCI_COMMAND_IO 0x01 > >> #define PCI_COMMAND_MEMORY 0x02 > >> +#define PCI_COMMAND_MASTER 0x4 /* Enable bus mastering */ > >> +#define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */ > >> > >> #define PCI_STATUS 0x06 /* 16 bits */ > >> #define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ > >> @@ -44,6 +46,11 @@ > >> #define PCI_BASE_ADDR_4 0x20 > >> #define PCI_BASE_ADDR_5 0x24 > >> > >> +#define PCI_IO_BASE 0x1c /* I/O range behind the bridge */ > >> +#define PCI_IO_LIMIT 0x1d > >> +#define PCI_MEMORY_BASE 0x20 /* Memory range behind */ > >> +#define PCI_MEMORY_LIMIT 0x22 > >> + > >> #define PCI_SUBSYSTEM_VENDOR_ID 0x2c > >> #define PCI_SUBSYSTEM_ID 0x2e > >> > >> -- > >> 1.7.2.5 > >> > > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 21:28 ` Michael S. Tsirkin @ 2012-03-04 21:54 ` Blue Swirl 2012-03-04 22:29 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 21:54 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Sun, Mar 4, 2012 at 21:28, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 08:32:26PM +0000, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 20:02, Michael S. Tsirkin <mst@redhat.com> wrote: >> > On Sun, Mar 04, 2012 at 07:51:02PM +0000, Blue Swirl wrote: >> >> On Sun, Mar 4, 2012 at 17:35, Michael S. Tsirkin <mst@redhat.com> wrote: >> >> > 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. >> >> >> >> Well, that is still according to device spec. >> > >> > I tried to find anything in the spec that says any register >> > after 0x10 is implemented but failed. >> > Can you tell me which chater and what it says? >> >> 19.3.1.10 tells that the header type is 0, as you noted too. Still, >> the register layout matches bridge spec instead, for example there are >> bus number registers in place of BAR 2. > > Sorry I don't see this in 19.3.1 > Where are these registers documented? > In my spec all registers from 0x10 on are greyed out which > it says above means 'not implemented'? > My spec also says 'Base Address' for 0x10 - 0x27. > > I see bus number and subordinate bus number > registers at 0x40 and 0x41, this is outside > the configuration header. The spec also says > they are unused. Oh, I somehow read that they were in bridge locations 0x18 and 0x19. Perhaps the is_bridge property should be removed after OpenBIOS no longer wants to write to the registers. > Are we looking at the same spec? Mine is copyright 1997. Yes, Part No.: 805-0087-01. >> This conflicts with bridge >> spec 3.2.4.9. Maybe the device predates the specification. > > bridge spec 1.0 was released in 1994, 1.1 in 1998. > This spec is from 1997, but the device might be older. > > >> >> >> > >> >> >> >> 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. >> >> >> >> I now know the root cause of the problem. OpenBIOS programs the BARs >> >> somewhat correctly just by accident. The initial io_base and mem_base >> >> for BARs are not correct, but because the host bridge BARs (and also 6 >> >> of which 4 are not even BARs!) are programmed first, the bases >> >> happened to settle to values that happen to work. The commit revealed >> >> the problem since the settling didn't happen. The mask changes just >> >> let the host bridge setup continue to do the magic. >> >> >> >> By just changing OpenBIOS (see attached patch), I can get the devices >> >> to work (assuming that VGA is a separate problem). There's no need to >> >> change QEMU. >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > MST >> > >> >> From 3f957e2dc8477f00f6d3a9491d81399ee750c725 Mon Sep 17 00:00:00 2001 >> >> Message-Id: <3f957e2dc8477f00f6d3a9491d81399ee750c725.1330890410.git.blauwirbel@gmail.com> >> >> From: Blue Swirl <blauwirbel@gmail.com> >> >> Date: Sun, 4 Mar 2012 19:46:38 +0000 >> >> Subject: [PATCH] pci: fix BAR setup >> >> >> >> A change in QEMU on how PCI bridges are setup revealed >> >> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >> >> happened to get somewhat correct values by accident before >> >> the commit but not after the change. >> >> >> >> Avoid to set up BARs for host bridge. Fix bridge >> >> check, this lead to setting up 6 BARs instead of more >> >> correct 2. If a bridge doesn't have any devices behind it, >> >> disable it entirely. Fix Sparc64 PCI memory base. >> >> >> >> Signed-off-by: Blue Swirl <blauwirbel@gmail.com> >> >> --- >> >> arch/sparc64/openbios.c | 2 +- >> >> drivers/pci.c | 67 ++++++++++++++++++++++++++++++++++------------ >> >> drivers/pci.h | 7 +++++ >> >> 3 files changed, 57 insertions(+), 19 deletions(-) >> >> >> >> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >> >> index ac709fe..a1544a8 100644 >> >> --- a/arch/sparc64/openbios.c >> >> +++ b/arch/sparc64/openbios.c >> >> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >> >> .cfg_base = APB_SPECIAL_BASE, >> >> .cfg_len = 0x2000000, >> >> .host_mem_base = APB_MEM_BASE, >> >> - .pci_mem_base = 0, >> >> + .pci_mem_base = 0x10000000, >> >> .mem_len = 0x10000000, >> >> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >> >> .io_len = 0x10000, >> >> diff --git a/drivers/pci.c b/drivers/pci.c >> >> index f8c6414..6ed0c03 100644 >> >> --- a/drivers/pci.c >> >> +++ b/drivers/pci.c >> >> @@ -966,11 +966,18 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, >> >> size = min_align; >> >> reloc = (reloc + size -1) & ~(size - 1); >> >> if (*io_base == base) { >> >> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >> >> + *io_base, reloc + size); >> >> *io_base = reloc + size; >> >> reloc -= arch->io_base; >> >> } else { >> >> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >> >> + *mem_base, reloc + size); >> >> *mem_base = reloc + size; >> >> } >> >> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >> >> + "io_base 0x%lx mem_base 0x%lx\n", >> >> + config->path, reloc, *p_omask, *io_base, *mem_base); >> >> pci_config_write32(addr, config_addr, reloc | *p_omask); >> >> config->assigned[reg] = reloc | *p_omask; >> >> } >> >> @@ -1021,26 +1028,30 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, >> >> pci_config_write16(addr, PCI_COMMAND, cmd); >> >> } >> >> >> >> -static void ob_configure_pci_device(const char* parent_path, >> >> - int *bus_num, unsigned long *mem_base, unsigned long *io_base, >> >> - int bus, int devnum, int fn, int *p_is_multi); >> >> +static int ob_configure_pci_device(const char* parent_path, >> >> + int *bus_num, unsigned long *mem_base, >> >> + unsigned long *io_base, int bus, int devnum, >> >> + int fn, int *p_is_multi); >> >> >> >> -static void ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, >> >> - unsigned long *io_base, const char *path, >> >> - int bus) >> >> +static int ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, >> >> + unsigned long *io_base, const char *path, >> >> + int bus) >> >> { >> >> - int devnum, fn, is_multi; >> >> + int devnum, fn, is_multi, ndevices = 0; >> >> >> >> PCI_DPRINTF("\nScanning bus %d at %s...\n", bus, path); >> >> >> >> for (devnum = 0; devnum < 32; devnum++) { >> >> is_multi = 0; >> >> for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { >> >> - ob_configure_pci_device(path, bus_num, mem_base, io_base, >> >> - bus, devnum, fn, &is_multi); >> >> + ndevices += ob_configure_pci_device(path, bus_num, >> >> + mem_base, io_base, >> >> + bus, devnum, fn, >> >> + &is_multi); >> >> >> >> } >> >> } >> >> + return ndevices; >> >> } >> >> >> >> static void ob_configure_pci_bridge(pci_addr addr, >> >> @@ -1048,6 +1059,9 @@ static void ob_configure_pci_bridge(pci_addr addr, >> >> unsigned long *io_base, >> >> int primary_bus, pci_config_t *config) >> >> { >> >> + int ndevices; >> >> + uint8_t command; >> >> + >> >> config->primary_bus = primary_bus; >> >> pci_config_write8(addr, PCI_PRIMARY_BUS, config->primary_bus); >> >> >> >> @@ -1062,16 +1076,30 @@ static void ob_configure_pci_bridge(pci_addr addr, >> >> >> >> /* make pci bridge parent device, prepare for recursion */ >> >> >> >> - ob_scan_pci_bus(bus_num, mem_base, io_base, >> >> - config->path, config->secondary_bus); >> >> + ndevices = ob_scan_pci_bus(bus_num, mem_base, io_base, >> >> + config->path, config->secondary_bus); >> >> + if (!ndevices) { >> >> + /* no devices, disable bridging */ >> >> + PCI_DPRINTF("disabling bridge %s\n", config->path); >> >> + command = pci_config_read8(addr, PCI_COMMAND); >> >> + command &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | >> >> + PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_MASTER); >> >> + pci_config_write8(addr, PCI_COMMAND, command); >> >> + pci_config_write8(addr, PCI_IO_BASE, 0); >> >> + pci_config_write8(addr, PCI_IO_LIMIT, 0); >> >> + pci_config_write8(addr, PCI_MEMORY_BASE, 0); >> >> + pci_config_write8(addr, PCI_MEMORY_LIMIT, 0); >> >> + return; >> >> + } >> >> >> >> /* bus scan updates *bus_num to last revealed pci bus number */ >> >> config->subordinate_bus = *bus_num; >> >> pci_config_write8(addr, PCI_SUBORDINATE_BUS, config->subordinate_bus); >> >> >> >> - PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d\n", >> >> - config->path, config->primary_bus, config->secondary_bus, >> >> - config->subordinate_bus); >> >> + PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d" >> >> + " ndev=%d\n", >> >> + config->path, config->primary_bus, config->secondary_bus, >> >> + config->subordinate_bus, ndevices); >> >> >> >> pci_set_bus_range(config); >> >> } >> >> @@ -1117,7 +1145,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, >> >> return 1; >> >> } >> >> >> >> -static void ob_configure_pci_device(const char* parent_path, >> >> +static int ob_configure_pci_device(const char* parent_path, >> >> int *bus_num, unsigned long *mem_base, unsigned long *io_base, >> >> int bus, int devnum, int fn, int *p_is_multi) >> >> { >> >> @@ -1133,7 +1161,7 @@ static void ob_configure_pci_device(const char* parent_path, >> >> int is_host_bridge = 0; >> >> >> >> if (!ob_pci_read_identification(bus, devnum, fn, &vid, &did, &class, &subclass)) { >> >> - return; >> >> + return 0; >> >> } >> >> >> >> addr = PCI_ADDR(bus, devnum, fn); >> >> @@ -1195,16 +1223,18 @@ static void ob_configure_pci_device(const char* parent_path, >> >> >> >> if (get_property(phandle, "vendor-id", NULL)) { >> >> PCI_DPRINTF("host bridge already configured\n"); >> >> - return; >> >> + return 0; >> >> } >> >> } >> >> >> >> activate_dev(phandle); >> >> >> >> - if (htype & PCI_HEADER_TYPE_BRIDGE) { >> >> + if (htype & PCI_HEADER_TYPE_BRIDGE || (class == PCI_BASE_CLASS_BRIDGE)) { >> >> + PCI_DPRINTF("Bridge 2 bars, htype %x\n", htype); >> >> num_bars = 2; >> >> rom_bar = PCI_ROM_ADDRESS1; >> >> } else { >> >> + PCI_DPRINTF("Device 6 bars, htype %x\n", htype); >> >> num_bars = 6; >> >> rom_bar = PCI_ROM_ADDRESS; >> >> } >> >> @@ -1240,6 +1270,7 @@ static void ob_configure_pci_device(const char* parent_path, >> >> >> >> ob_configure_pci_bridge(addr, bus_num, mem_base, io_base, bus, &config); >> >> } >> >> + return 1; >> >> } >> >> >> >> int ob_pci_init(void) >> >> diff --git a/drivers/pci.h b/drivers/pci.h >> >> index 0f6ae1f..4314507 100644 >> >> --- a/drivers/pci.h >> >> +++ b/drivers/pci.h >> >> @@ -7,6 +7,8 @@ >> >> #define PCI_COMMAND 0x04 >> >> #define PCI_COMMAND_IO 0x01 >> >> #define PCI_COMMAND_MEMORY 0x02 >> >> +#define PCI_COMMAND_MASTER 0x4 /* Enable bus mastering */ >> >> +#define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */ >> >> >> >> #define PCI_STATUS 0x06 /* 16 bits */ >> >> #define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ >> >> @@ -44,6 +46,11 @@ >> >> #define PCI_BASE_ADDR_4 0x20 >> >> #define PCI_BASE_ADDR_5 0x24 >> >> >> >> +#define PCI_IO_BASE 0x1c /* I/O range behind the bridge */ >> >> +#define PCI_IO_LIMIT 0x1d >> >> +#define PCI_MEMORY_BASE 0x20 /* Memory range behind */ >> >> +#define PCI_MEMORY_LIMIT 0x22 >> >> + >> >> #define PCI_SUBSYSTEM_VENDOR_ID 0x2c >> >> #define PCI_SUBSYSTEM_ID 0x2e >> >> >> >> -- >> >> 1.7.2.5 >> >> >> > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 21:54 ` Blue Swirl @ 2012-03-04 22:29 ` Michael S. Tsirkin 2012-03-05 18:34 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 22:29 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Sun, Mar 04, 2012 at 09:54:02PM +0000, Blue Swirl wrote: > >> 19.3.1.10 tells that the header type is 0, as you noted too. Still, > >> the register layout matches bridge spec instead, for example there are > >> bus number registers in place of BAR 2. > > > > Sorry I don't see this in 19.3.1 > > Where are these registers documented? > > In my spec all registers from 0x10 on are greyed out which > > it says above means 'not implemented'? > > My spec also says 'Base Address' for 0x10 - 0x27. > > > > I see bus number and subordinate bus number > > registers at 0x40 and 0x41, this is outside > > the configuration header. The spec also says > > they are unused. > > Oh, I somehow read that they were in bridge locations 0x18 and 0x19. > Perhaps the is_bridge property should be removed after OpenBIOS no > longer wants to write to the registers. So we are in agreement then? The device seems to (more or less) go by the spec, but openbios gets confused, apparently by the absence of BARs. Can you try debugging openbios to see what is wrong? -- MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 22:29 ` Michael S. Tsirkin @ 2012-03-05 18:34 ` Blue Swirl 2012-03-06 13:42 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-05 18:34 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Sun, Mar 4, 2012 at 22:29, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 09:54:02PM +0000, Blue Swirl wrote: >> >> 19.3.1.10 tells that the header type is 0, as you noted too. Still, >> >> the register layout matches bridge spec instead, for example there are >> >> bus number registers in place of BAR 2. >> > >> > Sorry I don't see this in 19.3.1 >> > Where are these registers documented? >> > In my spec all registers from 0x10 on are greyed out which >> > it says above means 'not implemented'? >> > My spec also says 'Base Address' for 0x10 - 0x27. >> > >> > I see bus number and subordinate bus number >> > registers at 0x40 and 0x41, this is outside >> > the configuration header. The spec also says >> > they are unused. >> >> Oh, I somehow read that they were in bridge locations 0x18 and 0x19. >> Perhaps the is_bridge property should be removed after OpenBIOS no >> longer wants to write to the registers. > > So we are in agreement then? > The device seems to (more or less) go by the spec, QEMU is correct here as is your original commit. The only change (beside bug fixes for the problems you found, thanks) should be for is_bridge. > but openbios gets confused, apparently by the absence of BARs. > > Can you try debugging openbios to see what is wrong? On second thought, I think 32 bit I/O was confusing OpenBIOS, probably the host bridge device not so much. PCI handling in OpenBIOS should be fixed. > -- > MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-05 18:34 ` Blue Swirl @ 2012-03-06 13:42 ` Michael S. Tsirkin 0 siblings, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-06 13:42 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori On Mon, Mar 05, 2012 at 06:34:51PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 22:29, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Mar 04, 2012 at 09:54:02PM +0000, Blue Swirl wrote: > >> >> 19.3.1.10 tells that the header type is 0, as you noted too. Still, > >> >> the register layout matches bridge spec instead, for example there are > >> >> bus number registers in place of BAR 2. > >> > > >> > Sorry I don't see this in 19.3.1 > >> > Where are these registers documented? > >> > In my spec all registers from 0x10 on are greyed out which > >> > it says above means 'not implemented'? > >> > My spec also says 'Base Address' for 0x10 - 0x27. > >> > > >> > I see bus number and subordinate bus number > >> > registers at 0x40 and 0x41, this is outside > >> > the configuration header. The spec also says > >> > they are unused. > >> > >> Oh, I somehow read that they were in bridge locations 0x18 and 0x19. > >> Perhaps the is_bridge property should be removed after OpenBIOS no > >> longer wants to write to the registers. > > > > So we are in agreement then? > > The device seems to (more or less) go by the spec, > > QEMU is correct here as is your original commit. The only change > (beside bug fixes for the problems you found, thanks) should be for > is_bridge. You mean remove is_bridge? Right. > > but openbios gets confused, apparently by the absence of BARs. > > > > Can you try debugging openbios to see what is wrong? > > On second thought, I think 32 bit I/O was confusing OpenBIOS, probably > the host bridge device not so much. PCI handling in OpenBIOS should be > fixed. We can make IO 32 bit. Want to try? Anyway, so I won't revert this in core for now? > > -- > > MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 19:51 ` Blue Swirl 2012-03-04 20:02 ` Michael S. Tsirkin @ 2012-03-04 21:56 ` Mark Cave-Ayland 1 sibling, 0 replies; 41+ messages in thread From: Mark Cave-Ayland @ 2012-03-04 21:56 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1116 bytes --] On 04/03/12 19:51, Blue Swirl wrote: > I now know the root cause of the problem. OpenBIOS programs the BARs > somewhat correctly just by accident. The initial io_base and mem_base > for BARs are not correct, but because the host bridge BARs (and also 6 > of which 4 are not even BARs!) are programmed first, the bases > happened to settle to values that happen to work. The commit revealed > the problem since the settling didn't happen. The mask changes just > let the host bridge setup continue to do the magic. > > By just changing OpenBIOS (see attached patch), I can get the devices > to work (assuming that VGA is a separate problem). There's no need to > change QEMU. Hi Blue/Michael, Thanks for debugging this. I can confirm that building OpenBIOS SVN trunk with Blue's patch and testing against QEMU git master with the attached patch (to temporarily back out 2b50aa1f14d8e0a40f905ad0c022443c15646914 and de58ac72b6a062d1a61478284c0c0f8a0428613e which breaks VGA on PPC/SPARC64) appears to fix the problem for me. Thanks a lot to both of you for taking the time to track this down :) ATB, Mark. [-- Attachment #2: qemu-mem-revert.patch --] [-- Type: text/x-diff, Size: 7390 bytes --] diff --git a/ioport.c b/ioport.c index 8a474d3..36fa3a4 100644 --- a/ioport.c +++ b/ioport.c @@ -328,7 +328,6 @@ void portio_list_init(PortioList *piolist, piolist->ports = callbacks; piolist->nr = 0; piolist->regions = g_new0(MemoryRegion *, n); - piolist->aliases = g_new0(MemoryRegion *, n); piolist->address_space = NULL; piolist->opaque = opaque; piolist->name = name; @@ -337,7 +336,6 @@ void portio_list_init(PortioList *piolist, void portio_list_destroy(PortioList *piolist) { g_free(piolist->regions); - g_free(piolist->aliases); } static void portio_list_add_1(PortioList *piolist, @@ -347,7 +345,7 @@ static void portio_list_add_1(PortioList *piolist, { MemoryRegionPortio *pio; MemoryRegionOps *ops; - MemoryRegion *region, *alias; + MemoryRegion *region; unsigned i; /* Copy the sub-list and null-terminate it. */ @@ -364,20 +362,12 @@ static void portio_list_add_1(PortioList *piolist, ops->old_portio = pio; region = g_new(MemoryRegion, 1); - alias = g_new(MemoryRegion, 1); - /* - * Use an alias so that the callback is called with an absolute address, - * rather than an offset relative to to start + off_low. - */ memory_region_init_io(region, ops, piolist->opaque, piolist->name, - UINT64_MAX); - memory_region_init_alias(alias, piolist->name, - region, start + off_low, off_high - off_low); + off_high - off_low); + memory_region_set_offset(region, start + off_low); memory_region_add_subregion(piolist->address_space, - start + off_low, alias); - piolist->regions[piolist->nr] = region; - piolist->aliases[piolist->nr] = alias; - ++piolist->nr; + start + off_low, region); + piolist->regions[piolist->nr++] = region; } void portio_list_add(PortioList *piolist, @@ -419,19 +409,15 @@ void portio_list_add(PortioList *piolist, void portio_list_del(PortioList *piolist) { - MemoryRegion *mr, *alias; + MemoryRegion *mr; unsigned i; for (i = 0; i < piolist->nr; ++i) { mr = piolist->regions[i]; - alias = piolist->aliases[i]; - memory_region_del_subregion(piolist->address_space, alias); - memory_region_destroy(alias); + memory_region_del_subregion(piolist->address_space, mr); memory_region_destroy(mr); g_free((MemoryRegionOps *)mr->ops); g_free(mr); - g_free(alias); piolist->regions[i] = NULL; - piolist->aliases[i] = NULL; } } diff --git a/ioport.h b/ioport.h index ab29c89..ae3e9da 100644 --- a/ioport.h +++ b/ioport.h @@ -60,7 +60,6 @@ typedef struct PortioList { struct MemoryRegion *address_space; unsigned nr; struct MemoryRegion **regions; - struct MemoryRegion **aliases; void *opaque; const char *name; } PortioList; diff --git a/memory.c b/memory.c index 6565e2e..926201a 100644 --- a/memory.c +++ b/memory.c @@ -389,17 +389,17 @@ static void memory_region_iorange_read(IORange *iorange, *data = ((uint64_t)1 << (width * 8)) - 1; if (mrp) { - *data = mrp->read(mr->opaque, offset); + *data = mrp->read(mr->opaque, offset + mr->offset); } else if (width == 2) { mrp = find_portio(mr, offset, 1, false); assert(mrp); - *data = mrp->read(mr->opaque, offset) | - (mrp->read(mr->opaque, offset + 1) << 8); + *data = mrp->read(mr->opaque, offset + mr->offset) | + (mrp->read(mr->opaque, offset + mr->offset + 1) << 8); } return; } *data = 0; - access_with_adjusted_size(offset, data, width, + access_with_adjusted_size(offset + mr->offset, data, width, mr->ops->impl.min_access_size, mr->ops->impl.max_access_size, memory_region_read_accessor, mr); @@ -416,16 +416,16 @@ static void memory_region_iorange_write(IORange *iorange, const MemoryRegionPortio *mrp = find_portio(mr, offset, width, true); if (mrp) { - mrp->write(mr->opaque, offset, data); + mrp->write(mr->opaque, offset + mr->offset, data); } else if (width == 2) { mrp = find_portio(mr, offset, 1, false); assert(mrp); - mrp->write(mr->opaque, offset, data & 0xff); - mrp->write(mr->opaque, offset + 1, data >> 8); + mrp->write(mr->opaque, offset + mr->offset, data & 0xff); + mrp->write(mr->opaque, offset + mr->offset + 1, data >> 8); } return; } - access_with_adjusted_size(offset, &data, width, + access_with_adjusted_size(offset + mr->offset, &data, width, mr->ops->impl.min_access_size, mr->ops->impl.max_access_size, memory_region_write_accessor, mr); @@ -796,6 +796,7 @@ void memory_region_init(MemoryRegion *mr, mr->size = int128_2_64(); } mr->addr = 0; + mr->offset = 0; mr->subpage = false; mr->enabled = true; mr->terminates = false; @@ -857,7 +858,7 @@ static uint64_t memory_region_dispatch_read1(MemoryRegion *mr, } /* FIXME: support unaligned access */ - access_with_adjusted_size(addr, &data, size, + access_with_adjusted_size(addr + mr->offset, &data, size, mr->ops->impl.min_access_size, mr->ops->impl.max_access_size, memory_region_read_accessor, mr); @@ -911,7 +912,7 @@ static void memory_region_dispatch_write(MemoryRegion *mr, } /* FIXME: support unaligned access */ - access_with_adjusted_size(addr, &data, size, + access_with_adjusted_size(addr + mr->offset, &data, size, mr->ops->impl.min_access_size, mr->ops->impl.max_access_size, memory_region_write_accessor, mr); @@ -1054,6 +1055,11 @@ bool memory_region_is_rom(MemoryRegion *mr) return mr->ram && mr->readonly; } +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset) +{ + mr->offset = offset; +} + void memory_region_set_log(MemoryRegion *mr, bool log, unsigned client) { uint8_t mask = 1 << client; diff --git a/memory.h b/memory.h index b7bccd1..a9cd586 100644 --- a/memory.h +++ b/memory.h @@ -115,6 +115,7 @@ struct MemoryRegion { MemoryRegion *parent; Int128 size; target_phys_addr_t addr; + target_phys_addr_t offset; void (*destructor)(MemoryRegion *mr); ram_addr_t ram_addr; IORange iorange; @@ -370,6 +371,14 @@ bool memory_region_is_rom(MemoryRegion *mr); void *memory_region_get_ram_ptr(MemoryRegion *mr); /** + * memory_region_set_offset: Sets an offset to be added to MemoryRegionOps + * callbacks. + * + * This function is deprecated and should not be used in new code. + */ +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset); + +/** * memory_region_set_log: Turn dirty logging on or off for a region. * * Turns dirty logging on or off for a specified client (display, migration). ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 14:35 ` Blue Swirl 2012-03-04 15:22 ` Michael S. Tsirkin @ 2012-03-04 15:41 ` Michael S. Tsirkin 1 sibling, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 15:41 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:37 ` Blue Swirl 2012-03-04 13:28 ` Michael S. Tsirkin @ 2012-03-04 13:38 ` Michael S. Tsirkin 1 sibling, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 13:38 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori 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. The following is likely also needed, maybe the define should be shared with apb. diff --git a/hw/sun4u.c b/hw/sun4u.c index 423108f..19a135a 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -81,7 +81,7 @@ #define FW_CFG_SPARC64_HEIGHT (FW_CFG_ARCH_LOCAL + 0x01) #define FW_CFG_SPARC64_DEPTH (FW_CFG_ARCH_LOCAL + 0x02) -#define MAX_PILS 16 +#define MAX_PILS 32 #define TICK_MAX 0x7fffffffffffffffULL ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 10:27 ` Blue Swirl 2012-03-04 12:21 ` Michael S. Tsirkin @ 2012-03-04 12:28 ` Avi Kivity 2012-03-04 12:38 ` Blue Swirl 2012-03-04 12:33 ` Michael S. Tsirkin 2 siblings, 1 reply; 41+ messages in thread From: Avi Kivity @ 2012-03-04 12:28 UTC (permalink / raw) To: Blue Swirl Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, Michael S. Tsirkin 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? -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:28 ` Avi Kivity @ 2012-03-04 12:38 ` Blue Swirl 2012-03-04 12:41 ` Avi Kivity 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 12:38 UTC (permalink / raw) To: Avi Kivity Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, Michael S. Tsirkin 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 > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:38 ` Blue Swirl @ 2012-03-04 12:41 ` Avi Kivity 2012-03-04 12:46 ` Blue Swirl 2012-03-04 13:22 ` Michael S. Tsirkin 0 siblings, 2 replies; 41+ messages in thread From: Avi Kivity @ 2012-03-04 12:41 UTC (permalink / raw) To: Blue Swirl Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, Michael S. Tsirkin 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. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:41 ` Avi Kivity @ 2012-03-04 12:46 ` Blue Swirl 2012-03-04 13:21 ` Michael S. Tsirkin 2012-03-04 13:22 ` Michael S. Tsirkin 1 sibling, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 12:46 UTC (permalink / raw) To: Avi Kivity Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, Michael S. Tsirkin 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 > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:46 ` Blue Swirl @ 2012-03-04 13:21 ` Michael S. Tsirkin 0 siblings, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 13:21 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel 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 > > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:41 ` Avi Kivity 2012-03-04 12:46 ` Blue Swirl @ 2012-03-04 13:22 ` Michael S. Tsirkin 2012-03-04 13:33 ` Blue Swirl 1 sibling, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 13:22 UTC (permalink / raw) To: Avi Kivity; +Cc: Blue Swirl, Mark Cave-Ayland, qemu-devel, Anthony Liguori 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 13:22 ` Michael S. Tsirkin @ 2012-03-04 13:33 ` Blue Swirl 2012-03-04 14:08 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 13:33 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 4, 2012 at 13:22, Michael S. Tsirkin <mst@redhat.com> wrote: > 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. This is later, the crash happens when IDE driver is accessing CMD646 registers after the PCI device is configured. I changed OpenBIOS to disable any bridges with no devices, but that didn't help. It looks like this is not related to bridges, I disabled the secondary bridges with this patch and still there is the crash. diff --git a/hw/apb_pci.c b/hw/apb_pci.c index 1d25da8..ed9dc68 100644 --- a/hw/apb_pci.c +++ b/hw/apb_pci.c @@ -256,11 +256,13 @@ static const MemoryRegionOps pci_ioport_ops = { .endianness = DEVICE_NATIVE_ENDIAN, }; +#if 0 /* The APB host has an IRQ line for each IRQ line of each slot. */ static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num) { return ((pci_dev->devfn & 0x18) >> 1) + irq_num; } +#endif static int pci_pbm_map_irq(PCIDevice *pci_dev, int irq_num) { @@ -322,8 +324,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, SysBusDevice *s; APBState *d; unsigned int i; +#if 0 PCIDevice *pci_dev; PCIBridge *br; +#endif /* Ultrasparc PBM main bus */ dev = qdev_create(NULL, "pbm"); @@ -352,6 +356,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, pci_create_simple(d->bus, 0, "pbm-pci"); +#if 0 /* APB secondary busses */ pci_dev = pci_create_multifunction(d->bus, PCI_DEVFN(1, 0), true, "pbm-bridge"); @@ -368,7 +373,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, pci_apb_map_irq); qdev_init_nofail(&pci_dev->qdev); *bus3 = pci_bridge_get_sec_bus(br); - +#endif return d->bus; } > >> -- >> error compiling committee.c: too many arguments to function ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 13:33 ` Blue Swirl @ 2012-03-04 14:08 ` Michael S. Tsirkin 2012-03-04 14:26 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 14:08 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 04, 2012 at 01:33:42PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 13:22, Michael S. Tsirkin <mst@redhat.com> wrote: > > 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. > > This is later, the crash happens when IDE driver is accessing CMD646 > registers after the PCI device is configured. > > I changed OpenBIOS to disable any bridges with no devices, but that > didn't help. It looks like this is not related to bridges, I disabled > the secondary bridges with this patch and still there is the crash. It seems to have to do with the host bridge. It's unusual to have host bridge present itself as a pci to pci bridge but there it is. > diff --git a/hw/apb_pci.c b/hw/apb_pci.c > index 1d25da8..ed9dc68 100644 > --- a/hw/apb_pci.c > +++ b/hw/apb_pci.c > @@ -256,11 +256,13 @@ static const MemoryRegionOps pci_ioport_ops = { > .endianness = DEVICE_NATIVE_ENDIAN, > }; > > +#if 0 > /* The APB host has an IRQ line for each IRQ line of each slot. */ > static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num) > { > return ((pci_dev->devfn & 0x18) >> 1) + irq_num; > } > +#endif > > static int pci_pbm_map_irq(PCIDevice *pci_dev, int irq_num) > { > @@ -322,8 +324,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, > SysBusDevice *s; > APBState *d; > unsigned int i; > +#if 0 > PCIDevice *pci_dev; > PCIBridge *br; > +#endif > > /* Ultrasparc PBM main bus */ > dev = qdev_create(NULL, "pbm"); > @@ -352,6 +356,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, > > pci_create_simple(d->bus, 0, "pbm-pci"); > > +#if 0 > /* APB secondary busses */ > pci_dev = pci_create_multifunction(d->bus, PCI_DEVFN(1, 0), true, > "pbm-bridge"); > @@ -368,7 +373,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, > pci_apb_map_irq); > qdev_init_nofail(&pci_dev->qdev); > *bus3 = pci_bridge_get_sec_bus(br); > - > +#endif > return d->bus; > } > > > > >> -- > >> error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 14:08 ` Michael S. Tsirkin @ 2012-03-04 14:26 ` Blue Swirl 2012-03-04 16:42 ` Michael S. Tsirkin 0 siblings, 1 reply; 41+ messages in thread From: Blue Swirl @ 2012-03-04 14:26 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 4, 2012 at 14:08, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 01:33:42PM +0000, Blue Swirl wrote: >> On Sun, Mar 4, 2012 at 13:22, Michael S. Tsirkin <mst@redhat.com> wrote: >> > 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. >> >> This is later, the crash happens when IDE driver is accessing CMD646 >> registers after the PCI device is configured. >> >> I changed OpenBIOS to disable any bridges with no devices, but that >> didn't help. It looks like this is not related to bridges, I disabled >> the secondary bridges with this patch and still there is the crash. > > It seems to have to do with the host bridge. > It's unusual to have host bridge present itself > as a pci to pci bridge but there it is. It looks like the I/O base calculations in OpenBIOS are confused by host bridge, after that all BARs are wrong. OpenBIOS also thinks that the host bridge is a device and attempts to configure six BARs instead of two. >> diff --git a/hw/apb_pci.c b/hw/apb_pci.c >> index 1d25da8..ed9dc68 100644 >> --- a/hw/apb_pci.c >> +++ b/hw/apb_pci.c >> @@ -256,11 +256,13 @@ static const MemoryRegionOps pci_ioport_ops = { >> .endianness = DEVICE_NATIVE_ENDIAN, >> }; >> >> +#if 0 >> /* The APB host has an IRQ line for each IRQ line of each slot. */ >> static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num) >> { >> return ((pci_dev->devfn & 0x18) >> 1) + irq_num; >> } >> +#endif >> >> static int pci_pbm_map_irq(PCIDevice *pci_dev, int irq_num) >> { >> @@ -322,8 +324,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, >> SysBusDevice *s; >> APBState *d; >> unsigned int i; >> +#if 0 >> PCIDevice *pci_dev; >> PCIBridge *br; >> +#endif >> >> /* Ultrasparc PBM main bus */ >> dev = qdev_create(NULL, "pbm"); >> @@ -352,6 +356,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, >> >> pci_create_simple(d->bus, 0, "pbm-pci"); >> >> +#if 0 >> /* APB secondary busses */ >> pci_dev = pci_create_multifunction(d->bus, PCI_DEVFN(1, 0), true, >> "pbm-bridge"); >> @@ -368,7 +373,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, >> pci_apb_map_irq); >> qdev_init_nofail(&pci_dev->qdev); >> *bus3 = pci_bridge_get_sec_bus(br); >> - >> +#endif >> return d->bus; >> } >> >> > >> >> -- >> >> error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 14:26 ` Blue Swirl @ 2012-03-04 16:42 ` Michael S. Tsirkin 2012-03-04 17:49 ` Blue Swirl 0 siblings, 1 reply; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 16:42 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 04, 2012 at 02:26:13PM +0000, Blue Swirl wrote: > > It seems to have to do with the host bridge. > > It's unusual to have host bridge present itself > > as a pci to pci bridge but there it is. > > It looks like the I/O base calculations in OpenBIOS are confused Where's the source for that, BTW? Have build instructions? > by > host bridge, after that all BARs are wrong. OpenBIOS also thinks that > the host bridge is a device and attempts to configure six BARs instead > of two. According to the spec it is a device, so should be ok? If I just make BAR4 writeable we get past the bios screen at least. Maybe openbios gets confused if a device has no BARs? Do things work for you with the patch below? All it does is make BAR4 writeable, accesses go nowhere. diff --git a/hw/apb_pci.c b/hw/apb_pci.c index 1d25da8..fae841f 100644 --- a/hw/apb_pci.c +++ b/hw/apb_pci.c @@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d) pci_set_word(d->config + PCI_STATUS, PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ | PCI_STATUS_DEVSEL_MEDIUM); + pci_set_long(d->wmask + 0x20, 0xfffffff0); return 0; } @@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass, void *data) k->vendor_id = PCI_VENDOR_ID_SUN; k->device_id = PCI_DEVICE_ID_SUN_SABRE; k->class_id = PCI_CLASS_BRIDGE_HOST; - k->is_bridge = 1; } static TypeInfo pbm_pci_host_info = { -- MST ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 16:42 ` Michael S. Tsirkin @ 2012-03-04 17:49 ` Blue Swirl 2012-03-04 18:11 ` Mark Cave-Ayland 2012-03-04 19:27 ` Michael S. Tsirkin 0 siblings, 2 replies; 41+ messages in thread From: Blue Swirl @ 2012-03-04 17:49 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 4, 2012 at 16:42, Michael S. Tsirkin <mst@redhat.com> wrote: > On Sun, Mar 04, 2012 at 02:26:13PM +0000, Blue Swirl wrote: >> > It seems to have to do with the host bridge. >> > It's unusual to have host bridge present itself >> > as a pci to pci bridge but there it is. >> >> It looks like the I/O base calculations in OpenBIOS are confused > > Where's the source for that, BTW? Have build instructions? Under roms/openbios or www.openbios.org. You need xsltproc. ../config/scripts/switch-arch sparc64 make build-verbose qemu-system-sparc64 -bios obj-sparc64/openbios-builtin.elf.nostrip >> by >> host bridge, after that all BARs are wrong. OpenBIOS also thinks that >> the host bridge is a device and attempts to configure six BARs instead >> of two. > > According to the spec it is a device, so should be ok? > If I just make BAR4 writeable we get past the > bios screen at least. > Maybe openbios gets confused if a device has no BARs? > Do things work for you with the patch below? > All it does is make BAR4 writeable, accesses go nowhere. Looking at serial console, there is no crash, but VGA still does not work. > > > diff --git a/hw/apb_pci.c b/hw/apb_pci.c > index 1d25da8..fae841f 100644 > --- a/hw/apb_pci.c > +++ b/hw/apb_pci.c > @@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d) > pci_set_word(d->config + PCI_STATUS, > PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ | > PCI_STATUS_DEVSEL_MEDIUM); > + pci_set_long(d->wmask + 0x20, 0xfffffff0); > return 0; > } > > @@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass, void *data) > k->vendor_id = PCI_VENDOR_ID_SUN; > k->device_id = PCI_DEVICE_ID_SUN_SABRE; > k->class_id = PCI_CLASS_BRIDGE_HOST; > - k->is_bridge = 1; > } > > static TypeInfo pbm_pci_host_info = { > -- > MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 17:49 ` Blue Swirl @ 2012-03-04 18:11 ` Mark Cave-Ayland 2012-03-04 19:27 ` Michael S. Tsirkin 2012-03-04 19:43 ` Michael S. Tsirkin 2012-03-04 19:27 ` Michael S. Tsirkin 1 sibling, 2 replies; 41+ messages in thread From: Mark Cave-Ayland @ 2012-03-04 18:11 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel, Avi Kivity, Anthony Liguori, Michael S. Tsirkin On 04/03/12 17:49, Blue Swirl wrote: >> According to the spec it is a device, so should be ok? >> If I just make BAR4 writeable we get past the >> bios screen at least. >> Maybe openbios gets confused if a device has no BARs? >> Do things work for you with the patch below? >> All it does is make BAR4 writeable, accesses go nowhere. > > Looking at serial console, there is no crash, but VGA still does not work. Note that I've just emailed the list about a VGA regression I've found on PPC caused by one of Avi's commits - perhaps Michael's fix does work, but you're being bitten by the same bug? ATB, Mark. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 18:11 ` Mark Cave-Ayland @ 2012-03-04 19:27 ` Michael S. Tsirkin 2012-03-04 19:43 ` Michael S. Tsirkin 1 sibling, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 19:27 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: Blue Swirl, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 04, 2012 at 06:11:20PM +0000, Mark Cave-Ayland wrote: > On 04/03/12 17:49, Blue Swirl wrote: > > >>According to the spec it is a device, so should be ok? > >>If I just make BAR4 writeable we get past the > >>bios screen at least. > >>Maybe openbios gets confused if a device has no BARs? > >>Do things work for you with the patch below? > >>All it does is make BAR4 writeable, accesses go nowhere. > > > >Looking at serial console, there is no crash, but VGA still does not work. > > Note that I've just emailed the list about a VGA regression I've > found on PPC caused by one of Avi's commits - perhaps Michael's fix > does work, but you're being bitten by the same bug? > > > ATB, > > Mark. It's not a fix as such - just a hack to see what makes bios crash. -- MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 18:11 ` Mark Cave-Ayland 2012-03-04 19:27 ` Michael S. Tsirkin @ 2012-03-04 19:43 ` Michael S. Tsirkin 1 sibling, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 19:43 UTC (permalink / raw) To: Mark Cave-Ayland; +Cc: Blue Swirl, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 04, 2012 at 06:11:20PM +0000, Mark Cave-Ayland wrote: > On 04/03/12 17:49, Blue Swirl wrote: > > >>According to the spec it is a device, so should be ok? > >>If I just make BAR4 writeable we get past the > >>bios screen at least. > >>Maybe openbios gets confused if a device has no BARs? > >>Do things work for you with the patch below? > >>All it does is make BAR4 writeable, accesses go nowhere. > > > >Looking at serial console, there is no crash, but VGA still does not work. > > Note that I've just emailed the list about a VGA regression I've > found on PPC caused by one of Avi's commits - perhaps Michael's fix > does work, but you're being bitten by the same bug? > > > ATB, > > Mark. Can you pls try applying my patch on top of old tree where VGA did work, and see what happens? -- MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 17:49 ` Blue Swirl 2012-03-04 18:11 ` Mark Cave-Ayland @ 2012-03-04 19:27 ` Michael S. Tsirkin 1 sibling, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 19:27 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, Avi Kivity, Anthony Liguori, qemu-devel On Sun, Mar 04, 2012 at 05:49:04PM +0000, Blue Swirl wrote: > On Sun, Mar 4, 2012 at 16:42, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Sun, Mar 04, 2012 at 02:26:13PM +0000, Blue Swirl wrote: > >> > It seems to have to do with the host bridge. > >> > It's unusual to have host bridge present itself > >> > as a pci to pci bridge but there it is. > >> > >> It looks like the I/O base calculations in OpenBIOS are confused > > > > Where's the source for that, BTW? Have build instructions? > > Under roms/openbios or www.openbios.org. You need xsltproc. > ../config/scripts/switch-arch sparc64 > make build-verbose > qemu-system-sparc64 -bios obj-sparc64/openbios-builtin.elf.nostrip I don't see anything obviously wrong in there, but the behaviour does seem to indicate some firmware bug ... I don't have the right toolchain - care debugging? > >> by > >> host bridge, after that all BARs are wrong. OpenBIOS also thinks that > >> the host bridge is a device and attempts to configure six BARs instead > >> of two. > > > > According to the spec it is a device, so should be ok? > > If I just make BAR4 writeable we get past the > > bios screen at least. > > Maybe openbios gets confused if a device has no BARs? > > Do things work for you with the patch below? > > All it does is make BAR4 writeable, accesses go nowhere. > > Looking at serial console, there is no crash, but VGA still does not work. What do info pci/ifo mtree show now? > > > > > > diff --git a/hw/apb_pci.c b/hw/apb_pci.c > > index 1d25da8..fae841f 100644 > > --- a/hw/apb_pci.c > > +++ b/hw/apb_pci.c > > @@ -433,6 +433,7 @@ static int pbm_pci_host_init(PCIDevice *d) > > pci_set_word(d->config + PCI_STATUS, > > PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ | > > PCI_STATUS_DEVSEL_MEDIUM); > > + pci_set_long(d->wmask + 0x20, 0xfffffff0); > > return 0; > > } > > > > @@ -444,7 +445,6 @@ static void pbm_pci_host_class_init(ObjectClass *klass, void *data) > > k->vendor_id = PCI_VENDOR_ID_SUN; > > k->device_id = PCI_DEVICE_ID_SUN_SABRE; > > k->class_id = PCI_CLASS_BRIDGE_HOST; > > - k->is_bridge = 1; > > } > > > > static TypeInfo pbm_pci_host_info = { > > -- > > MST ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 10:27 ` Blue Swirl 2012-03-04 12:21 ` Michael S. Tsirkin 2012-03-04 12:28 ` Avi Kivity @ 2012-03-04 12:33 ` Michael S. Tsirkin 2012-03-04 12:35 ` Avi Kivity ` (2 more replies) 2 siblings, 3 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 12:33 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, avi 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 > > This unassigned memory exception is triggered because CMD646 IDE I/O > registers are not accessible: So here's a theory: the issue is that both device IO and bridge IO have the same priority. Bridge is initialized with IO at 0 to 4K and so we have two devices at the same priority. And flipping a type bit affects this, by chance? I tried the following and it seems to help. But the real fix IMO is to either disable the bridge ranges at reset, in hardware, or have the BIOS do this. Avi, could you pls comment on my analysis? diff --git a/hw/pci.c b/hw/pci.c index 6d08cef..286383a 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d) r->addr = new_addr; if (r->addr != PCI_BAR_UNMAPPED) { memory_region_add_subregion_overlap(r->address_space, - r->addr, r->memory, 1); + r->addr, r->memory, 2); } } } ^ permalink raw reply related [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:33 ` Michael S. Tsirkin @ 2012-03-04 12:35 ` Avi Kivity 2012-03-04 12:35 ` Michael S. Tsirkin 2012-03-04 12:42 ` Blue Swirl 2 siblings, 0 replies; 41+ messages in thread From: Avi Kivity @ 2012-03-04 12:35 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Blue Swirl, Mark Cave-Ayland, qemu-devel, Anthony Liguori On 03/04/2012 02:33 PM, Michael S. Tsirkin wrote: > On Sun, Mar 04, 2012 at 10:27:24AM +0000, Blue Swirl wrote: > > On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <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: > > So here's a theory: the issue is that both device IO > and bridge IO have the same priority. > Bridge is initialized with IO at 0 to 4K > and so we have two devices at the same priority. > And flipping a type bit affects this, by chance? What device shares its BAR with the bridge I/O window? > I tried the following and it seems to help. > But the real fix IMO is to either disable the bridge ranges > at reset, in hardware, or have the BIOS do this. > > Avi, could you pls comment on my analysis? > > diff --git a/hw/pci.c b/hw/pci.c > index 6d08cef..286383a 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d) > r->addr = new_addr; > if (r->addr != PCI_BAR_UNMAPPED) { > memory_region_add_subregion_overlap(r->address_space, > - r->addr, r->memory, 1); > + r->addr, r->memory, 2); > } > } > } Who says a BAR has higher priority than a bridge? -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:33 ` Michael S. Tsirkin 2012-03-04 12:35 ` Avi Kivity @ 2012-03-04 12:35 ` Michael S. Tsirkin 2012-03-04 12:42 ` Blue Swirl 2 siblings, 0 replies; 41+ messages in thread From: Michael S. Tsirkin @ 2012-03-04 12:35 UTC (permalink / raw) To: Blue Swirl; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, avi On Sun, Mar 04, 2012 at 02:33:02PM +0200, Michael S. Tsirkin wrote: > On Sun, Mar 04, 2012 at 10:27:24AM +0000, Blue Swirl wrote: > > On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin <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: > > So here's a theory: the issue is that both device IO > and bridge IO have the same priority. > Bridge is initialized with IO at 0 to 4K > and so we have two devices at the same priority. > And flipping a type bit affects this, by chance? > > I tried the following and it seems to help. > But the real fix IMO is to either disable the bridge ranges > at reset, in hardware, or have the BIOS do this. > > Avi, could you pls comment on my analysis? > > diff --git a/hw/pci.c b/hw/pci.c > index 6d08cef..286383a 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d) > r->addr = new_addr; > if (r->addr != PCI_BAR_UNMAPPED) { > memory_region_add_subregion_overlap(r->address_space, > - r->addr, r->memory, 1); > + r->addr, r->memory, 2); > } > } > } Grr. Scap the above, the patch does nothing, I didn't test it right. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE 2012-03-04 12:33 ` Michael S. Tsirkin 2012-03-04 12:35 ` Avi Kivity 2012-03-04 12:35 ` Michael S. Tsirkin @ 2012-03-04 12:42 ` Blue Swirl 2 siblings, 0 replies; 41+ messages in thread From: Blue Swirl @ 2012-03-04 12:42 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Mark Cave-Ayland, qemu-devel, Anthony Liguori, avi On Sun, Mar 4, 2012 at 12:33, 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 >> >> This unassigned memory exception is triggered because CMD646 IDE I/O >> registers are not accessible: > > So here's a theory: the issue is that both device IO > and bridge IO have the same priority. > Bridge is initialized with IO at 0 to 4K > and so we have two devices at the same priority. > And flipping a type bit affects this, by chance? > > I tried the following and it seems to help. > But the real fix IMO is to either disable the bridge ranges > at reset, in hardware, or have the BIOS do this. I'd suppose bridge ranges should be disabled at reset. BIOS should probably also program the bridge ranges so that only devices behind the bridge are visible, or if no devices exist, disable the bridge completely. It's possible that all of these could be buggy and the original commit could be correct. > Avi, could you pls comment on my analysis? > > diff --git a/hw/pci.c b/hw/pci.c > index 6d08cef..286383a 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d) > r->addr = new_addr; > if (r->addr != PCI_BAR_UNMAPPED) { > memory_region_add_subregion_overlap(r->address_space, > - r->addr, r->memory, 1); > + r->addr, r->memory, 2); > } > } > } ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-03-06 13:42 UTC | newest] Thread overview: 41+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-04 9:46 [Qemu-devel] [PATCH] pci: fix bridge IO/BASE Michael S. Tsirkin 2012-03-04 10:27 ` Blue Swirl 2012-03-04 12:21 ` Michael S. Tsirkin 2012-03-04 12:37 ` Blue Swirl 2012-03-04 13:28 ` Michael S. Tsirkin 2012-03-04 13:38 ` Blue Swirl 2012-03-04 14:23 ` Michael S. Tsirkin 2012-03-04 14:35 ` Blue Swirl 2012-03-04 15:22 ` Michael S. Tsirkin 2012-03-04 17:07 ` Blue Swirl 2012-03-04 17:35 ` Michael S. Tsirkin 2012-03-04 19:51 ` Blue Swirl 2012-03-04 20:02 ` Michael S. Tsirkin 2012-03-04 20:32 ` Blue Swirl 2012-03-04 21:28 ` Michael S. Tsirkin 2012-03-04 21:54 ` Blue Swirl 2012-03-04 22:29 ` Michael S. Tsirkin 2012-03-05 18:34 ` Blue Swirl 2012-03-06 13:42 ` Michael S. Tsirkin 2012-03-04 21:56 ` Mark Cave-Ayland 2012-03-04 15:41 ` Michael S. Tsirkin 2012-03-04 13:38 ` Michael S. Tsirkin 2012-03-04 12:28 ` Avi Kivity 2012-03-04 12:38 ` Blue Swirl 2012-03-04 12:41 ` Avi Kivity 2012-03-04 12:46 ` Blue Swirl 2012-03-04 13:21 ` Michael S. Tsirkin 2012-03-04 13:22 ` Michael S. Tsirkin 2012-03-04 13:33 ` Blue Swirl 2012-03-04 14:08 ` Michael S. Tsirkin 2012-03-04 14:26 ` Blue Swirl 2012-03-04 16:42 ` Michael S. Tsirkin 2012-03-04 17:49 ` Blue Swirl 2012-03-04 18:11 ` Mark Cave-Ayland 2012-03-04 19:27 ` Michael S. Tsirkin 2012-03-04 19:43 ` Michael S. Tsirkin 2012-03-04 19:27 ` Michael S. Tsirkin 2012-03-04 12:33 ` Michael S. Tsirkin 2012-03-04 12:35 ` Avi Kivity 2012-03-04 12:35 ` Michael S. Tsirkin 2012-03-04 12:42 ` Blue Swirl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).