On 2011-10-17 15:48, Michael S. Tsirkin wrote: > 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 ... Yep, as MSI requests that land in the APIC MMIO page are also fed into msi_deliver and will take the normal path from there on. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
