From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEE4d-0002d7-6w for qemu-devel@nongnu.org; Tue, 27 Aug 2013 03:52:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEE4U-0003KC-PU for qemu-devel@nongnu.org; Tue, 27 Aug 2013 03:52:23 -0400 Received: from mail-ee0-x231.google.com ([2a00:1450:4013:c00::231]:55587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEE4U-0003K6-Hw for qemu-devel@nongnu.org; Tue, 27 Aug 2013 03:52:14 -0400 Received: by mail-ee0-f49.google.com with SMTP id d41so2077999eek.36 for ; Tue, 27 Aug 2013 00:52:13 -0700 (PDT) Date: Tue, 27 Aug 2013 09:52:11 +0200 From: Stefan Hajnoczi Message-ID: <20130827075211.GD24247@stefanha-thinkpad.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] AioContext, IOthread and Block migration thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yaodong Yang Cc: "qemu-devel@nongnu.org" On Mon, Aug 26, 2013 at 10:07:23AM -0500, Yaodong Yang wrote: > 1. Is it true that all the requests to disk images need to go through function bdrv_co_do_readv() or bdrv_co_do_writev()? Yes, read/write requests go through those functions. > 2. In block-migration thread, the bdrv_co_do_readv is also called to read blocks from disk images, in order to finish migration. How do migration thread and IOthread cooperate with each other? there is an coroutine created inside migration thread and a new botoom half created for this purpose, but I do not understand well about it. Could someone explain it for me? QEMU has a global mutex (big lock) that is used to protect shared data: /* In migration thread: */ qemu_mutex_lock_iothread(); bdrv_*(bs, ...); qemu_mutex_unlock_iothread(); > 3. What is the meaning of copy on read ? Copy-on-read means that an image file is populated when read requests are processed. It's used together with backing files: template.img <- vm001.qcow2 In the beginning vm001.qcow2 might be empty so all reads go to template.img. When copy-on-read is enabled, data read from template.img will be written to vm001.qcow2. The next time a read is made to the same sectors they can be fetched from vm001.qcow2 instead. This is a useful feature for migrating (copying) an image to a new file system while the guest is still running. It can also be used to reduce network load when template.img is on NFS. Stefan