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
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1608802
Title:
READ_DMA (0xC8) command does not work correctly
Status in QEMU:
Confirmed
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1608802/+subscriptions
