Re: [Qemu-devel] Bug in Sparc64/IDE Code

[Igor Kovalenko <igor.v.kovalenko@gmail.com>]

On Sat, Dec 12, 2009 at 3:18 PM, Igor Kovalenko
<igor.v.kovalenko@gmail.com> wrote:
> On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman <Nick.Couchman@seakr.com> 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.  The 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 recent issue indicates that the IDE code for the Sparc64 emulator is reading from and writing to the wrong memory locations.  The end result is the following 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 segfault?
>>
>
> 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 getting
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?

-- 
Kind regards,
Igor V. Kovalenko