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
