Am 02.08.2016 um 08:11 schrieb Stefan Weil: > Public bug reported: > > The QEMU PC emulation of DMA does not behave like real hardware or other > virtualization software. > > >From the original bug report (Benjamin David Lunt): > > Back to the READ_DMA command, it is my conclusion that the > READ_DMA command, more precisely, the BUS Master part of QEMU is > in error. The tests that people have done to see if it works, is > probably the guest finding out that DMA doesn't work and defaulting > to PIO, but since the read was successful visually to the user, the > user assumed the READ_DMA command works, where the guest actually > defaulted back to PIO transfers without notice. > > My code works on real hardware (numerous machines), Bochs, and Oracle's > Virtual Box. > > ... > > I have a small test suite, zipped and included at: > www.fysnet.net/temp/c8bug.zip > > Within this zip file is a.img. This is a freeDOS bootable > floppy. Emulate it with QEMU and then at the DOS prompt, run > c8bug.exe. > > It will say that the drive is not ready. > "Drive never became ready" > (along with a few other lines of text) > > The source for this test suite is also included. > c8bug.c is the c source code > c8bug.h is the header file > ctype.h is a quick way to get 'bit8u' type defines > timer.h is a delay routine from another project I have > (The base IO addresses are assumed and set at the top of c8bug.c) > (compiled with DJGPP for DPMI) > > q.bat is my command line for QEMU > > On all other machines and VirtualBox, the controller is ready > for me to receive the sector data. > "Drive is ready to transmit data..." > > However, in QEMU, the controller never becomes ready. > "Drive never became ready" > > The bug was reported for QEMU for Windows, but I can confirm that QEMU > for Linux also shows that behaviour, while VirtualBox works. > > ** Affects: qemu > Importance: Undecided > Status: Confirmed > > ** Description changed: > > The QEMU PC emulation of DMA does not behave like real hardware or other > virtualization software. > > From the original bug report (Benjamin David Lunt): > > - Back to the READ_DMA command, it is my conclusion that the > - READ_DMA command, more precisely, the BUS Master part of QEMU is > - in error. The tests that people have done to see if it works, is > - probably the guest finding out that DMA doesn't work and defaulting > - to PIO, but since the read was successful visually to the user, the > - user assumed the READ_DMA command works, where the guest actually > - defaulted back to PIO transfers without notice. > + Back to the READ_DMA command, it is my conclusion that the > + READ_DMA command, more precisely, the BUS Master part of QEMU is > + in error. The tests that people have done to see if it works, is > + probably the guest finding out that DMA doesn't work and defaulting > + to PIO, but since the read was successful visually to the user, the > + user assumed the READ_DMA command works, where the guest actually > + defaulted back to PIO transfers without notice. > > - My code works on real hardware (numerous machines), Bochs, and Oracle's > - Virtual Box. > + My code works on real hardware (numerous machines), Bochs, and Oracle's > + Virtual Box. > > - ... > + ... > > - I have a small test suite, zipped and included at: > - www.fysnet.net/temp/c8bug.zip > + I have a small test suite, zipped and included at: > + www.fysnet.net/temp/c8bug.zip > > - Within this zip file is a.img. This is a freeDOS bootable > - floppy. Emulate it with QEMU and then at the DOS prompt, run > - c8bug.exe. > + Within this zip file is a.img. This is a freeDOS bootable > + floppy. Emulate it with QEMU and then at the DOS prompt, run > + c8bug.exe. > > - It will say that the drive is not ready. > - "Drive never became ready" > - (along with a few other lines of text) > + It will say that the drive is not ready. > + "Drive never became ready" > + (along with a few other lines of text) > > - The source for this test suite is also included. > - c8bug.c is the c source code > - c8bug.h is the header file > - ctype.h is a quick way to get 'bit8u' type defines > - timer.h is a delay routine from another project I have > - (The base IO addresses are assumed and set at the top of c8bug.c) > - (compiled with DJGPP for DPMI) > + The source for this test suite is also included. > + c8bug.c is the c source code > + c8bug.h is the header file > + ctype.h is a quick way to get 'bit8u' type defines > + timer.h is a delay routine from another project I have > + (The base IO addresses are assumed and set at the top of c8bug.c) > + (compiled with DJGPP for DPMI) > > - q.bat is my command line for QEMU > + q.bat is my command line for QEMU > > - On all other machines and VirtualBox, the controller is ready > - for me to receive the sector data. > - "Drive is ready to transmit data..." > + On all other machines and VirtualBox, the controller is ready > + for me to receive the sector data. > + "Drive is ready to transmit data..." > > - However, in QEMU, the controller never becomes ready. > - "Drive never became ready" > + However, in QEMU, the controller never becomes ready. > + "Drive never became ready" > > - The bug was reported for QEMU for Windows, but I can confirm that QEMU for > Linux also shows that > - behaviour, while VirtualBox works. > + The bug was reported for QEMU for Windows, but I can confirm that QEMU > + for Linux also shows that behaviour, while VirtualBox works. > > ** Changed in: qemu > Status: New => Confirmed
Hi John, I got this bug report only recently from a Windows user, but it also occurs on Linux. As I don't know whether this is a regression or whether it is relevant for QEMU 2.7, it would be good if you and maybe more people could have a look on that problem, too. Kind regards, Stefan
