From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LY0T5-0004Xk-Os for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:00:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LY0T4-0004Ww-D6 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:00:43 -0500 Received: from [199.232.76.173] (port=60168 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LY0T4-0004Wm-92 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:00:42 -0500 Received: from mail2.shareable.org ([80.68.89.115]:44802) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LY0T3-0006M3-N8 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:00:41 -0500 Date: Fri, 13 Feb 2009 16:00:39 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Message-ID: <20090213160039.GG18471@shareable.org> References: <20090210212841.9760.96780.stgit@kvm.aw> <200902121705.54473.paul@codesourcery.com> <1234462898.25178.277.camel@bling> <200902131240.21150.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902131240.21150.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Alex Williamson , kvm@vger.kernel.org Paul Brook wrote: > > We could use a changed() function, but it would need to know the > > direction of the change, which leads back to the same mechanics. If > > there's a better way, please suggest it. Thanks, > > I still don't see why the device needs to know what's changed. The response > should always be the same: Request a filter, and see if it works. Well, you do need some way to notify a client that the filter which used to work has been removed because it's no longer available, for example when migrating between host kernels. Or implement reliable filtering in the infrastructure which relays packets internally in QEMU, so that each client can request a filter and it always works, and the tap driver can tell the QEMU infrastructure when kernel filtering is working and not, but each client doesn't need to know that. -- Jamie