On Sat, Mar 31, 2012 at 08:07:25PM +0800, Zhi Yong Wu wrote: > On Fri, Mar 30, 2012 at 6:29 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Fri, Mar 30, 2012 at 9:50 AM, <zwu.ker...@gmail.com> wrote: > >> + * When all sync I/O drivers are converted to async I/O, it will be > >> restored > >> + * to the original state. > > > > The problem here is that guess_disk_lchs() uses bdrv_read(), not > > whether device emulation uses sync or async I/O. Converting devices > > to async I/O will not fix this. > Yeah, but when all sync emulated devices drivers are converted to > async mode, the code change need to be rolled back. This is what i > mean.
There are places outside device emulation that call bdrv_read(), like guest_disk_lchs() and bdrv_commit(). We would need to convert them before it's safe to remove the code to disable I/O throttling in bdrv_read()/bdrv_write(). It's not okay to drop the code before all bdrv_read()/bdrv_write() callers that are in a code path where I/O limits can be enabled have been fixed (including guest_disk_lchs()) because a request that exceeds I/O limits would cause QEMU to hang. Once all devices have been converted it might be possible to temporarily disable throttling in bdrv_read()/bdrv_write() and never disable it permanently. This is because the bdrv_read()/bdrv_write() calls would only come from QEMU code that is not directly driven by the guest - here we probably don't need to apply I/O limits anyway. In other words, devices use bdrv_aio_*() and I/O limits apply, QEMU internal code might still use bdrv_read()/bdrv_write() and limits will not apply. Anyway, I think it's best to drop this part of the comment because it's more related to the disable code in bdrv_read()/bdrv_write() than to this patch. Stefan
