Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-04-04 11:55, Avi Kivity wrote:
> On 04/04/2012 12:38 PM, Jan Kiszka wrote:
>> On 2012-04-04 11:36, Avi Kivity wrote:
>>> On 04/04/2012 12:22 PM, Jan Kiszka wrote:
>>>>>
>>>>>>> Until we do have this fast path we can just fill this value with zeros,
>>>>>>> so kernel patch (almost) does not need to change for this -
>>>>>>> just the header.
>>>>>>
>>>>>> Partially implemented interfaces invite breakage.
>>>>>
>>>>> Hmm true. OK scrap this idea then, it's not clear
>>>>> whether we are going to optimize this anyway.
>>>>>
>>>>
>>>> Also, the problem is that keeping that ID in userspace requires an
>>>> infrastructure like the MSIRoutingCache that I proposed originally. Not
>>>> much won /wrt invasiveness there. 
>>>
>>> Internal qemu refactorings are not a driver for kvm interface changes.
>>
>> No, but qemu demonstrates the applicability and handiness of the kernel
>> interfaces.
> 
> True.
> 
>>>
>>>> So we should really do the routing
>>>> optimization in the kernel - one day.
>>>
>>> No, we need to make a choice:
>>>
>>> explicit handles: array lookup, more expensive setup
>>> no handles: hash loopup, more expensive, but no setup, and no artificial
>>> limits
>>
>> ...and I think we should head for option 2.
> 
> I'm not so sure anymore.  Sorry about the U turn, but remind me why?  In
> the long term it will be slower.

Likely not measurably slower. If you look at a message through the arch
glasses, you can usually spot the destination directly, specifically if
a message targets a single processor - no need for hashing and table
lookups in the common case.

In contrast, the maintenance costs for the current explicit route based
model are significant as we see now.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux