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

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

[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

-- 
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

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

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

[Kevin Wolf]

Okay, I think there are two parts to this, and both the test case and qemu are
buggy, though perhaps the test case more seriously than qemu.

The ATA spec describes DMA commands as having two phases, preparation and
transfer. During the first phase, BSY=1,DRQ=0 is required. In the second phase,
the device can use the same status (BSY=1,DRQ=0) or switch to BSY=0,DRQ=1.
I couldn't find clear information on which state the device should be in between
receiving the ATA command and enabling the bus master operation, which is what
the test case checks, but it must be one of the two.

So the reason that the test case is buggy is that it waits for DRQ to be set,
while the spec only guarantees that either DRQ or BSY is set during the
transfer. It doesn't work on hardware that sets BSY rather than DRQ. (It also
means that the test expects the device to be in the transfer state before the
bus master is enabled.)

The problem with qemu is that it sets _both_ bits, whereas the spec requires
that only one of them is set. Apparently most drivers don't care about this as
long as any of the bits is set, but technically it's wrong.

-- 
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

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

[Kevin Wolf]

Am 02.08.2016 um 08:52 hat Stefan Weil geschrieben:
> 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.
> 
> 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.

I don't think it's a regression. I commented with more detail in the bug
report, and despite the test case being buggy it seems to be true that
qemu doesn't get the flags completely right (we should set either BSY or
DRQ, but we do set both). Apparently none of the common drivers check
for this, though, so it never made any difference.

Kevin

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

[Benjamin David Lunt]

----- Original Message ----- 
> Am 02.08.2016 um 08:52 hat Stefan Weil geschrieben:
>> 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.
>>
>> 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.
>
> I don't think it's a regression. I commented with more detail in the bug
> report, and despite the test case being buggy it seems to be true that
> qemu doesn't get the flags completely right (we should set either BSY or
> DRQ, but we do set both). Apparently none of the common drivers check
> for this, though, so it never made any difference.
>
> Kevin

I agree that the controller is either BSY && !DRQ or !BSY && DRQ.
This is explained in section 9.7 of ATAPI v6, Page 354 (doc page 340).

My test was to simply show that the status remains 0xD8.
BSY *and* DRQ always set.

If a patch is made to make QEMU either BSY && !DRQ or !BSY && DRQ
after the DMA command, then I believe it will be correct.

I would guess that the common drivers, as you put it, don't check
for the status at all, but simply wait to see if an interrupt fires.

Thank you,
Ben

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

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

** Changed in: qemu
       Status: Confirmed => Incomplete

-- 
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:
  Incomplete

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

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

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
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:
  Expired

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