On Wed, Apr 27, 2011 at 05:01:09PM +0300, Avi Kivity wrote: > On 04/27/2011 04:54 PM, Jan Kiszka wrote: > >>> > >>> I was planning for a MSI short-path anyway. Also for TCG, it's pointless > >>> to go through lengthy stl_phys if we know it's supposed to be an MSI > >>> message. > >> > >> I don't think tcg will see much benefit; the decoding path through > >> hw/apic.c isn't complicated. > > > >stl_phys itself is non-trivial, e.g. due to phys_page_find. > > That is true. But consider that MSI delivery has to emulate > interrupt injection through the IDT... > > >> > >> Maybe an intermediate solution is to move kvm_hpet_msi_update() (with a > >> neutral name) into msi.c and have hpet call it whenever things change. > >> So hpet.c isn't aware of kvm directly. > > > >Without caching, you need per-vector tracking to refresh or drop routes. > >That's what the hooks are about. > > Right, my proposal doesn't really change your code, it simply moves > the kvm specific parts away from hpet.c. Instead of a general > cache, the caller is supposed to provide a unique KVMMsiMessage per > msi vector, so there is no cache management. > > >Intermediate solutions (like hacking msi.c now) are one thing. We also > >have to know where we can go to long-term. > > The really general case (allow generating an MSI via DMA, or allow > the device to write to non-MSI addresses via MSI generation) needs > the full blown cache. But while I've seen these techniques actually > used, I hope they're rare. You have? What uses these? As you pointed out earlier, we can make DMA to MSI work, slowly, by using a single gsi per apic. For the reverse, it's probably easiest to make it work by handling MSI outside the APIC range as a store in the kvm module in kernel. > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
