Re: QEMU PIC indirection patch for in-kernel APIC work

Avi Kivity
2007-04-05T06:40:34Z

Ingo Molnar wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>
>>> It still exists in userspace. Having the code duplication
>>> (especially when it's not the same code base) is unfortunate.
>>>
>> This remains true.
>>
>
> but it's the wrong argument. Of course there's duplicate functionality,
> and that's _good_ because it represents choice. KVM _itself_ is
> duplicate functionality of qemu in a way. So why move the lapic/PIC
> handling to the kernel? Because it's alot cleaner to do device emulation
> there and PV drivers get significantly easier to do. The lapic/PIC code
> should also be available in Qemu for OSs that dont have KVM-alike
> support in the kernel.
>

Duplicating code is never good, and duplicating code into the kernel
(where maintenance cost is much higher) is bad. There has to be a very
good reason for it. For the core kvm code, it is the 10x or more
performance increase over qemu. If we are to add *pic/pit to kvm, we
need to find an advantage that offsets the disadvantages. This can be a
combination of simpler interfaces and better performance.

> and while today most of the performance advantages of moving the PIC
> into the kernel are masked by the high cost of VM exits, in the future
> the effect will be more marked, as the relative cost of piggybacking out
> to qemu increases.
>

That is correct, but we need to quantify it. Assuming 3us per qemu exit
overhead, 30,000 events per second per core give us a 10% overall
overhead. That's >100K events/sec for an entry-level server.

> I can see the value in doing certain things in Qemu, but i cannot see
> _at all_ the value of handling say the PIT in Qemu. Just look at the
> Qemu PIT/timers code quality in Qemu for a change ... it's a huge ugly
> mess of lots of #ifdefs, ineffective handling of /dev/rtc, linear list
> walking, signal overhead, etc., etc.

Bad userspace code should be fixed, not rewritten as kernel code.

> All of that resulting in 10-15% of
> 'idle' overhead of KVM+qemu when it runs a Linux guest.

On my machines it's 0% overhead on idle (runlevel 3).

> On the other
> side, in the kernel it's most natural to do timers and to emulate
> hardware, because the kernel has _precise_ knowledge about the
> platform's capabilities.
>

That comes back to the kernel not exporting proper interfaces. I think
that's fixed now, with hrtimers tied to the userspace APIs?

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.