On Sun, Mar 13, 2016 at 02:37:21PM -0500, Huaicheng Li (coperd) wrote: > I meet some trouble in understanding IDE emulation: > > (1) IDE I/O Down Path (In VCPU thread): > upon KVM_EXIT_IO, corresponding disk ioport write function will write IO info > to IDEState, then ide read callback function will eventually split it into > **several DMA transfers** and eventually submit them to the AIO request list > for handling. > > (2). I/O Up Path (worker thread —> QEMU main loop thread) > when the request in AIO request list has been successfully handled, the > worker thread will signal the QEMU main thread this I/O completion event, > which is later handled by its callback (posix_aio_read). posix_aio_read will > then eventually return to IDE callback function, where virtual interrupt is > generated to signal guest about I/O completion. > > 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?
Yes it would be problematic. Is the case you are thinking about protected by the following code? void ide_exec_cmd(IDEBus *bus, uint32_t val) { ... /* Only RESET is allowed while BSY and/or DRQ are set, * and only to ATAPI devices. */ if (s->status & (BUSY_STAT|DRQ_STAT)) { if (val != WIN_DEVICE_RESET || s->drive_kind != IDE_CD) { return; } } If not, please try writing a test case or post the specific hardware register accesses you have in mind. Stefan
signature.asc
Description: PGP signature