Re: [Qemu-devel] about correctness of IDE emulation

[Stefan Hajnoczi]

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