[Qemu-devel] SD card subsystem synchronous I/O

[Stefan Hajnoczi]

Recently there have been new SD card emulation patches so I want to
raise the issue of synchronous I/O while there is focus on the SD
subsystem.  Maybe some of the people who are improving the SD
subsystem will be able to help.

sd_blk_read() and sd_blk_write() use the synchronous block I/O
functions to read/write data on behalf of the guest.  Device emulation
runs in the vcpu thread with the QEMU global mutex held, and therefore
both the guest vcpu and QEMU's own monitor and VNC server are
unresponsive while bdrv_read()/bdrv_write() is blocked.

This makes bdrv_read()/bdrv_write() in device emulation code a
performance problem - the guest becomes unresponsive and laggy under
heavy I/O.  In extreme cases, like image files on NFS with a network
connectivity issue, it can affect the reliability of QEMU as a whole
because the monitor and VNC are unavailable until the I/O operation
completes.

Device emulation should use the bdrv_aio_readv()/bdrv_aio_writev()
functions so that control can return to the guest.  When the I/O
operation completes a callback function is invoked and the device
emulation can signal completion to the guest - usually by setting bits
in hardware registers and raising an interrupt.  The result is good
responsiveness and the monitor/VNC remain available even under heavy
I/O.

The challenge is how to convert hw/sd.c and possibly update emulated
SD controllers.  We need to stop assuming that a read/write operation
can be performed instantly and need to use a
bdrv_aio_readv()/bdrv_aio_writev() callback function to complete the
I/O.

Since I am not familiar with the SD specification or the hw/sd.c code
very well I want to check:

* Is anyone willing to convert the SD subsystem?

* Will it be possible to convert just hw/sd.c without affecting
emulated SD controllers?
  * If we're going to need to fix all controllers in addition to
hw/sd.c, then adding more controllers grows the problem.

Stefan