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.
-- 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
