From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LYjoV-0007cF-TS
	for qemu-devel@nongnu.org; Sun, 15 Feb 2009 11:25:51 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LYjoU-0007be-Eq
	for qemu-devel@nongnu.org; Sun, 15 Feb 2009 11:25:51 -0500
Received: from [199.232.76.173] (port=47112 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LYjoU-0007bb-8t
	for qemu-devel@nongnu.org; Sun, 15 Feb 2009 11:25:50 -0500
Received: from mx20.gnu.org ([199.232.41.8]:15570)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1LYjoT-0004Ls-Un
	for qemu-devel@nongnu.org; Sun, 15 Feb 2009 11:25:50 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1LYjoR-0005DX-Ta
	for qemu-devel@nongnu.org; Sun, 15 Feb 2009 11:25:48 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for
	qemu_vlan_rxfilter
Date: Sun, 15 Feb 2009 16:25:39 +0000
References: <20090210212841.9760.96780.stgit@kvm.aw>
	<200902131704.49809.paul@codesourcery.com>
	<20090213203819.GC20328@shareable.org>
In-Reply-To: <20090213203819.GC20328@shareable.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902151625.39857.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org, Alex Williamson <alex.williamson@hp.com>

> The callback you suggest for devices requesting an inbound filter will
> infinite-loop when there's two such devices on the same vlan bus,
> because each time the callback is called, that device will re-issue
> its filter request which triggers the callback on the other similar
> device.  Back and forth.
>
> To avoid the infinite loop, the vlan code in the middle (if that's
> where you want it, and I agree) has to distinguish between no inbound
> filters requested by attached devices, and multiple incompatible
> inbound filters requested by attached devices.

Of course.

As I've said repeatedly, the only sane way to implement this is if you isolate 
individual devices from this kind of implementation detail. If you're API 
doesn't do that then it's wrong.

Paul