Re: KVM handling external interrupts

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

On 2012-06-10 12:43, Abel Gordon wrote:
> 
> 
> kvm-owner@vger.kernel.org wrote on 10/06/2012 13:16:01:
> 
>>> Yep, these are corner cases we should deal with but they are not part
>>> of the common case/critical path.
>>>
>>>> I'm wondering if redirecting (to different cores) or masking (at
>>>> device/IOAPIC/LAPIC level) of non-guest interrupts and only relying on
>>>> preemption timer/NMI isn't simpler. Then you wouldn't have to shadow
> the
>>>> IDT.
>>>
>>> Yep, as we suggested in the paper, that could be also an alternative.
>>> Is it really simpler ? Again, depends who you ask and what you need to
>>> change.
>>> All the alternatives have a set of pros and cons.
>>>
>> For sure. But avoiding the shadow IDT would likely mean avoiding
>> userspace changes for KVM. And that means simplification. And avoid PCI
>> dependencies.
> 
> But you lose flexibility. Remember that if you don't shadow the IDT
> you need at least one dedicated core that never uses ELI to handle
> all the physical interrupts. With the shadow IDT, you could enable
> ELI in all the cores.

You need to program the preemption timer anyway. Once you leave some
guest due to its expiry, you will re-enable the host IRQs and process them.

> In addition, if you don't use the shadow IDT, host interrupts will not
> be balanced across all the ELI cores. Thus, if you run many VMs/VCPU, you
> might experience higher latency/bottlenecks or have scalability
> problems unless you use a shadow IDT (depending on the workload,
> offcourse).

That might be an issue.

My feeling is software-based ELI could be a transitional feature (until
hardware supports it properly) and may focus more on static setups where
you have dedicated cores for guests and separated I/O processing.

In any case, I would suggest to start small, mostly self-contained, ie.
with changes that stay within KVM as far as possible. If that is
accepted, you could suggest more sophisticated mechanisms on top,
addressing more use cases.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]