From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [RFC][PATCH 11/45] msi: Factor out delivery hook
Date: Mon, 17 Oct 2011 15:48:14 +0200
Message-ID: <20111017134814.GE6406@redhat.com>
References: <cover.1318843693.git.jan.kiszka@siemens.com>
	<d13aab98dc5c08fa2473511e006365b3a4bbee3f.1318843693.git.jan.kiszka@siemens.com>
	<4E9C09E7.2010106@redhat.com> <4E9C0E6C.2070809@siemens.com>
	<20111017134135.GC6406@redhat.com> <4E9C3098.4080804@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
Content-Disposition: inline
In-Reply-To: <4E9C3098.4080804@redhat.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On Mon, Oct 17, 2011 at 03:41:44PM +0200, Avi Kivity wrote:
> On 10/17/2011 03:41 PM, Michael S. Tsirkin wrote:
> > On Mon, Oct 17, 2011 at 01:15:56PM +0200, Jan Kiszka wrote:
> > > On 2011-10-17 12:56, Avi Kivity wrote:
> > > > On 10/17/2011 11:27 AM, Jan Kiszka wrote:
> > > >> So far we deliver MSI messages by writing them into the target MMIO
> > > >> area. This reflects what happens on hardware, but imposes some
> > > >> limitations on the emulation when introducing KVM in-kernel irqchip
> > > >> models. For those we will need to track the message origin.
> > > > 
> > > > Why do we need to track the message origin?  Emulated interrupt remapping?
> > > 
> > > The origin holds the routing cache which we need to track if the message
> > > already has a route (and that without searching long lists) and to
> > > update that route instead of add another one.
> >
> > Hmm, yes, but if the device does stl_phys or something like this,
> > it won't work with irqchip, will it? And it should, ideally.
> 
> Why not?  it will fall back to the apic path, and use the local routing
> cache entry there.

Does it still work with irqchip enabled? I didn't realize ...

> -- 
> error compiling committee.c: too many arguments to function