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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
