From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJvm6-0003b2-O5 for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:14:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJvm2-0003WG-0c for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:14:42 -0500 Received: from [199.232.76.173] (port=40018 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJvm1-0003W4-Sz for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:14:37 -0500 Received: from mail-bw0-f212.google.com ([209.85.218.212]:53817) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJvm1-0000Ze-Ev for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:14:37 -0500 Received: by bwz4 with SMTP id 4so1644712bwz.2 for ; Sun, 13 Dec 2009 13:14:35 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <4B22461602000099000327DE@collaborate.seakr.com> Date: Mon, 14 Dec 2009 00:14:10 +0300 Message-ID: From: Igor Kovalenko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: Bug in Sparc64/IDE Code List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Blue Swirl , qemu-devel@nongnu.org, Nick Couchman On Sun, Dec 13, 2009 at 10:06 PM, Juan Quintela wrote= : > Igor Kovalenko wrote: >> On Sat, Dec 12, 2009 at 3:18 PM, Igor Kovalenko >> wrote: >>> On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl wrot= e: >>>> On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman wrote: >>>>> In working to try to get Sparc64 system emulation developed, we seem = to have run into an issue with the IDE code in Qemu. =A0The OpenBIOS folks = have been working quite a few issues with the OpenBIOS code that need to be= resolved in order to boot 64-bit Solaris kernels correctly, but the most r= ecent issue indicates that the IDE code for the Sparc64 emulator is reading= from and writing to the wrong memory locations. =A0The end result is the f= ollowing output when trying to boot off an ISO image in Qemu: >>>> >>>>> bmdma_cmd_writeb: 0x00000054 >>>>> bmdma: writeb 0x701 : 0xd7 >>>>> bmdma: writeb 0x702 : 0x79 >>>>> bmdma: writeb 0x703 : 0xfe >>>>> bmdma_addr_writew: 0x0000ddef >>>>> bmdma_addr_writew: 0x0000b12b >>>>> bmdma_cmd_writeb: 0x000000da >>>>> bmdma: writeb 0x709 : 0x95 >>>>> Segmentation fault >>>> >>>> I can't reproduce this with milaX 0.3.1, QEMU git HEAD and OpenBIOS >>>> svn r644. The bug could be that the BMDMA address may need BE to LE >>>> conversion, or OpenBIOS could just clobber BMDMA registers with >>>> garbage (the DMA address candidates 0xddefb12b and 0xb12bddef do not >>>> look valid). >>>> >>>> Another possibility is that the PCI host bridge should have an IOMMU >>>> which is not implemented yet, but I doubt we are at that stage. >>>> >>>> Could you run QEMU in a GDB session and send the backtrace from the se= gfault? >>>> >>> >>> There seems to be an issue with pci_from_bm cast: bm->unit is not >>> assigned anywhere >>> in the code so it is zero for second unit, and pci_from_bm returns >>> wrong address. >>> Crash happens writing to address mapped for second unit. >> >> This appears to be a regression in cmd646. After removal of pci_dev from >> BMDMAState structure we cannot do much to work around this issue. >> >> The problem here is that we cannot rely on bm->unit value since it is ge= tting >> changed while dma operations are in progress, f.e. it is set to -1 on >> dma cancel. >> Thus we cannot get to pci_dev from BMDMAState passed to i/o read/write >> callbacks. >> >> Juan, can you please take a look at this issue? > > =A0 I don't have a sparc setup, but could you try this patch? =A0It also = fixes > =A0 the test for bm. Looks good, but runtime aborts in register_ioport_read. You cannot install different opaque for read and write of the same i/o addr= ess. Seems like every other device has the same driver for reading and writing, but in cmd646 it calls out to ide/pci.c code for bmdma_cmd_writeb write method, whereas it reads with own bmdma_readb_0 method. Probably bmdma_writeb_* should call out to bmdma_cmd_writeb for address 0 and whole 4 byte is to be mapped to bmdma_writeb_* I tested the following fix on top of yours patch with my previous workaroun= d reverted. Both my workaround and these two combined show the same qemu.log trace. commit 26c618af44c91a806d88044d468733b86028e352 Author: Igor V. Kovalenko Date: Mon Dec 14 00:05:10 2009 +0300 cmd646 fix abort due to changed opaque pointer for ioport read Signed-off-by: Igor V. Kovalenko diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c index 9d60590..07fcf4d 100644 --- a/hw/ide/cmd646.c +++ b/hw/ide/cmd646.c @@ -123,6 +123,9 @@ static void bmdma_writeb_common(PCIIDEState *pci_dev, BMDMAState *bm, printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val); #endif switch(addr & 3) { + case 0: + bmdma_cmd_writeb(bm, addr, val); + break; case 1: pci_dev->dev.config[MRDMODE] =3D (pci_dev->dev.config[MRDMODE] & ~0x30) | (val & 0x30); @@ -168,13 +171,11 @@ static void bmdma_map(PCIDevice *pci_dev, int region_= num, bm->bus =3D d->bus+i; qemu_add_vm_change_state_handler(ide_dma_restart_cb, bm); - register_ioport_write(addr, 1, 1, bmdma_cmd_writeb, bm); - if (i =3D=3D 0) { - register_ioport_write(addr + 1, 3, 1, bmdma_writeb_0, d); + register_ioport_write(addr, 4, 1, bmdma_writeb_0, d); register_ioport_read(addr, 4, 1, bmdma_readb_0, d); } else { - register_ioport_write(addr + 1, 3, 1, bmdma_writeb_1, d); + register_ioport_write(addr, 4, 1, bmdma_writeb_1, d); register_ioport_read(addr, 4, 1, bmdma_readb_1, d); } --=20 Kind regards, Igor V. Kovalenko