On 2012-03-28 14:32, Avi Kivity wrote: > On 03/28/2012 01:54 PM, Jan Kiszka wrote: >>> >>>>> >>>>>> interface transparent. We create those routes on demand and keep them >>>>>> in a hash table. Succeeding messages can then search for an existing >>>>>> route in the table first and reuse it whenever possible. If we should >>>>>> run out of limited GSIs, we simply flush the table and rebuild it as >>>>>> messages are sent. >>>>>> >>>>>> This approach is rather simple and could be optimized further. However, >>>>>> it is more efficient to enhance the KVM API so that we do not need this >>>>>> clumsy dynamic routing over futures kernels. >>>>> >>>>> Two APIs are clumsier than one. >>>> >>>> The current one is very clumsy for user-injected MSIs while the new one >>>> won't be. It will also be very simple it implement if you recall the >>>> patch. I think that is worth it. >>> >>> Don't see why. The clumsiness will be retained. The cpu doesn't care >>> how clumsy the API is, only the reader. >> >> We won't have to do any hashing/caching over the new API, just a plain >> "deliver this MSI" IOCTL. Specifically all our upcoming archs like Power >> and ARM will be able to take the shiny highway instead of the winding >> countryside road. > > Upcoming archs are a good card to play. However that code will remain > for x86, and there's nothing arch specific about it, is there? Other archs that support MSI will then always come with something like KVM_CAP_SET_MSI, our signal to take the fast lane. x86 with be the only arch to potentially miss this cap. So, yes, we will always need the code for old x86 (as long as we support it), but we should not enforce this logic on anyone else. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
