first say sorry for the same mail sent more than one time, I don't know it will take so long time to come back. hi, stefan: thank for your explaining. how about to remove kvm_handle_io/handle_mmio in kvm_run function into kvm_main_loop, as these operation belong to io operation, this will remove the qemu_mutux between the 2 threads. is this an reasonable thought? In order to keep the monitor to response to user quicker under this suition, an easier way is to take monito io out of qemu_mutux protection. this include vnc/serial/telnet io related with monitor, as these io will not affect the running of vm itself, it need not in so stirct protection. Any suggestions? thanks. Green. 2011/3/1 Stefan Hajnoczi <stefanha@xxxxxxxxx>: > On Tue, Mar 1, 2011 at 5:01 AM, ya su <suya94335@xxxxxxxxx> wrote: >> kvm start with disk image on nfs server, when nfs server can not be >> reached, monitor will be blocked. I change io_thread to SCHED_RR >> policy, it will work unfluently waiting for disk read/write timeout. > > There are some synchronous disk image reads that can put qemu-kvm to > sleep until NFS responds or errors. For example, when starting > hw/virtio-blk.c calls bdrv_guess_geometry() which may invoke > bdrv_read(). > > Once the VM is running and you're using virtio-blk then disk I/O > should be asynchronous. There are some synchronous cases to do with > migration, snapshotting, etc where we wait for outstanding aio > requests. Again this can block qemu-kvm. > > So in short, there's no easy way to avoid blocking the VM in all cases > today. You should find, however, that normal read/write operation to > a running VM does not cause qemu-kvm to sleep. > > Stefan > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html