> On Mar 13, 2016, at 8:42 PM, Fam Zheng <f...@redhat.com> wrote: > > On Sun, 03/13 14:37, Huaicheng Li (coperd) wrote: >> Hi all, >> >> What I’m confused about is that: >> >> If one I/O is too large and may need several rounds (say 2) of DMA transfers, >> it seems the second round transfer begins only after the completion of the >> first part, by reading data from **IDEState**. But the IDEState info may have >> been changed by VCPU threads (by writing new I/Os to it) when the first >> transfer finishes. From the code, I see that IDE r/w call back function will >> continue the second transfer by referencing IDEState’s information. Wouldn’t >> this be problematic? Am I missing anything here? > > Can you give an concrete example? I/O in VCPU threads that changes IDEState > must also take care of the DMA transfers, for example ide_reset() has > blk_aio_cancel and clears s->nsectors. If an I/O handler fails to do so, it is > a bug. > > Fam
I get it now. ide_exec_cmd() can only proceed when BUSY_STAT|DRQ_STAT is not set. When the 2nd DMA transfer continues, BUSY_STAT | DRQ_STAT is already set, i.e., no other new ide_exec_cmd() can enter. BSUY or DRQ is removed only when all DMA transfers are done, after which new writes to IDE are allowed. Thus it’s safe. Thanks, Fam & Stefan.
