From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6gRZ-0000QZ-35 for qemu-devel@nongnu.org; Tue, 27 Apr 2010 04:47:01 -0400 Received: from [140.186.70.92] (port=40871 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6gRT-0000PB-Sn for qemu-devel@nongnu.org; Tue, 27 Apr 2010 04:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6gRJ-00058x-My for qemu-devel@nongnu.org; Tue, 27 Apr 2010 04:46:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5513) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6gRJ-00058I-DH for qemu-devel@nongnu.org; Tue, 27 Apr 2010 04:46:45 -0400 Message-ID: <4BD6A4CA.6070306@redhat.com> Date: Tue, 27 Apr 2010 11:48:10 +0300 From: Dor Laor MIME-Version: 1.0 References: <20100426172634.GC15278@x200.localdomain> <4BD5D28C.7080700@codemonkey.ws> <20100426221258.GH15278@x200.localdomain> <4BD61584.9080208@codemonkey.ws> <4BD69D03.2050502@redhat.com> In-Reply-To: <4BD69D03.2050502@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KVM call agenda for Apr 27 Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Chris Wright , Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org On 04/27/2010 11:14 AM, Avi Kivity wrote: > On 04/27/2010 01:36 AM, Anthony Liguori wrote: >> >> A few comments: >> >> 1) The problem was not block watermark itself but generating a >> notification on the watermark threshold. It's a heuristic and should >> be implemented based on polling block stats. > > Polling for an event that never happens is bad engineering. What > frequency do you poll? you're forcing the user to make a lose-lose > tradeoff. > >> Otherwise, we'll be adding tons of events to qemu that we'll struggle >> to maintain. > > That's not a valid reason to reject a user requirement. We may argue the > requirement is bogus, or that the suggested implementation is wrong and > point in a different direction, but saying that we may have to add more > code in the future due to other requirements is ... well I can't find a > word for it. > >> >> 2) A block plugin doesn't solve the problem if it's just at the >> BlockDriverState level because it can't interact with qcow2. > > Why not? We have a layered model. guest -> qcow2 -> plugin (sends event) > -> raw-posix. Just need to insert the plugin at the appropriate layer. > >> >> 3) For general block plugins, it's probably better to tackle userspace >> block devices. We have CUSE and FUSE already, a BUSE is a logical >> conclusion. > > We also have an nbd client. > > Here's another option: an nbd-like protocol that remotes all BlockDriver > operations except read and write over a unix domain socket. The open > operation returns an fd (SCM_RIGHTS strikes again) that is used for read > and write. This can be used to implement snapshots over LVM, for example. > Why w/o read/writes? the watermark code needs them too (as info, not the actual buffer). IMHO the whole thing is way over engineered: a) Having another channel into qemu is complicating management software. Isn't the monitor should be the channel? Otherwise we'll need to create another QMP (or nbd like Avi suggest) for these actions. It's extra work for mgmt and they will have hard time to understand events interleaving of the various channels b) How the plugins are defined? Is it scripts? Binaries? Do they open their own sockets? So I suggest either to stick with qmp or to have new block layer but let qmp pass events from it - this is actually the nbd-like approach but with qmp socket. Thanks, Dor