qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] ide: fix DMA register transitions


From: John Snow
Subject: Re: [Qemu-devel] [PATCH] ide: fix DMA register transitions
Date: Wed, 3 Aug 2016 09:19:30 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0



On 08/03/2016 05:24 AM, Kevin Wolf wrote:
Am 03.08.2016 um 07:06 hat Stefan Weil geschrieben:
Am 03.08.2016 um 00:05 schrieb John Snow:
ATA8-APT defines the state transitions for both a host controller and
for the hardware device during the lifecycle of a DMA transfer, in
section 9.7 "DMA command protocol."

One of the interesting tidbits here is that when a device transitions
from DDMA0 ("Prepare state") to DDMA1 ("Data_Transfer State"), it can
choose to set either BSY or DRQ to signal this transition, but not both.

as ide_sector_dma_start is the last point in our preparation process
before we begin the real data transfer process (for either AHCI or BMDMA),
this is the correct transition point for DDMA0 to DDMA1.

I have chosen !BSY && DRQ for QEMU to make the transition from DDMA0 the
most obvious.

Reported-by: Benjamin David Lunt <address@hidden>
Signed-off-by: John Snow <address@hidden>
---
 hw/ide/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index d117b7c..e961d42 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -907,7 +907,7 @@ eot:

 static void ide_sector_start_dma(IDEState *s, enum ide_dma_cmd dma_cmd)
 {
-    s->status = READY_STAT | SEEK_STAT | DRQ_STAT | BUSY_STAT;
+    s->status = READY_STAT | SEEK_STAT | DRQ_STAT;
     s->io_buffer_size = 0;
     s->dma_cmd = dma_cmd;


This patch fixes the reported test case, thank you.

Tested-by: Stefan Weil <address@hidden>

Reviewed-by: Kevin Wolf <address@hidden>

Benjamin, you'll still want to fix your driver code. If John had chosen
BSY && !DRQ, which is an equally valid option, qemu would be working
correctly, but your test case would still hang.

Kevin


I also have to admit that I misread the report; I was under the impression that this was affecting Linux/Windows guests in some capacity, but re-reading the report I realize that you meant that you have observed behavior with a test case on Windows and Linux *hosts*.

As such, I'll be staging this for 2.8 instead of 2.7 unless there's strong arguments for its inclusion in 2.7 during freeze.

--js



reply via email to

[Prev in Thread] Current Thread [Next in Thread]