From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJRvn-0004gJ-Ic for qemu-devel@nongnu.org; Sat, 12 Dec 2009 08:22:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJRvi-0004eE-Rl for qemu-devel@nongnu.org; Sat, 12 Dec 2009 08:22:43 -0500 Received: from [199.232.76.173] (port=59750 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJRvi-0004eB-KY for qemu-devel@nongnu.org; Sat, 12 Dec 2009 08:22:38 -0500 Received: from mail-bw0-f212.google.com ([209.85.218.212]:48169) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJRvi-000128-05 for qemu-devel@nongnu.org; Sat, 12 Dec 2009 08:22:38 -0500 Received: by bwz4 with SMTP id 4so1155641bwz.2 for ; Sat, 12 Dec 2009 05:22:37 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <4B22461602000099000327DE@collaborate.seakr.com> Date: Sat, 12 Dec 2009 16:22:37 +0300 Message-ID: Subject: Re: [Qemu-devel] Bug in Sparc64/IDE Code From: Igor Kovalenko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Juan Quintela , qemu-devel@nongnu.org, Nick Couchman On Sat, Dec 12, 2009 at 3:18 PM, Igor Kovalenko wrote: > On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl wrote: >> 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 ha= ve been working quite a few issues with the OpenBIOS code that need to be r= esolved in order to boot 64-bit Solaris kernels correctly, but the most rec= ent issue indicates that the IDE code for the Sparc64 emulator is reading f= rom and writing to the wrong memory locations. =A0The end result is the fol= lowing 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 segf= ault? >> > > 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 getti= ng 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? --=20 Kind regards, Igor V. Kovalenko