From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NerzD-0001wi-B2 for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:26:47 -0500 Received: from [199.232.76.173] (port=33267 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NerzC-0001wO-TJ for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:26:46 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NerzB-0006KS-Ck for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:26:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46586) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NerzB-0006KI-14 for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:26:45 -0500 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 2/4] block: add block topology options References: <20100129190417.GA25237@lst.de> <20100129190440.GA25287@lst.de> <4B69C7DF.9000900@codemonkey.ws> <20100205130956.GA17475@lst.de> <4B6C565D.8070608@codemonkey.ws> Date: Tue, 09 Feb 2010 16:26:33 +0100 In-Reply-To: <4B6C565D.8070608@codemonkey.ws> (Anthony Liguori's message of "Fri, 05 Feb 2010 11:33:17 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Christoph Hellwig , "Martin K. Petersen" , qemu-devel@nongnu.org Anthony Liguori writes: > On 02/05/2010 07:09 AM, Christoph Hellwig wrote: >> On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote: >> >>> But I don't think this is the wrong place to do it. The >>> BlockDriverState reflects that backing device, not the emulated device >>> itself. In this case, you're trying to set a property of the emulated >>> device. >>> >> I think that's very borderline. While the emulated device exposes these >> properties, they are in fact a property of the backing storage, the >> right sector and min/max I/O sizes are determined by the backing storage >> device. >> > > It's guest visible state that should be configured based on the > properties of the backing store. > > However, as you said, live migration complicates things. > > drive is not an optimal interface because it mixes host and guest > state. Qdev separates guest and host stuff. -device does guest, -netdev, -chardev, -drive if=none do host. Unfortunately, -drive can also do host, with other values for parameter if. A clean, host-only -blockdev for use with -device would be nice to have. > But the subset of -drive that you normally use should be > independent of the guest. To be precise: those properties that make sense with if=none. > For instance, with: > > -drive file=/home/anthony/foo.img,cache=off,aio=native,id=foo -device > virtio-blk-pci,drive=foo There's an implied if=ide, which means it's mixed host and guest stuff. > file, cache, and aio are all host properties. They have no visible > impact to the guest and if I change those properties during live > migration, they take affect without the guest noticing > > These topology options still can be specified via -drive, but the > proper way of splitting things would have them as part of the -device > option. During live migration, things on the -device side inherited > as part of the live migration process. If it's guest-visible, it should live in guest state (qdev device state), and be configured with -device. Else, it should live in host state (block driver state), and be configured via -drive if=none (or -blockdev once we have it). [...]