Re: [Qemu-devel] [Bug 1608802] [NEW] READ_DMA (0xC8) command does not work correctly

[Stefan Weil]

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