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

[Igor Kovalenko]

On Sat, Dec 12, 2009 at 3:18 PM, Igor Kovalenko
<address@hidden> wrote:
> On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl <address@hidden> wrote:
>> On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman <address@hidden> 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