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

Dor Laor
2007-04-04T16:27:28Z

>>>>
>>>> This pushes towards in kernel apic too. Can't see how we avoid it.
>>>>
>>>
>>> Does it really? IIUC, we would avoid TPR traps entirely and would
>>> just need to synchronize the TPR whenever we go down to userspace.
>>>
>>
>> It's a bit more complex than that, as userspace would need to tell
the
>> kernel the highest priority pending interrupt so that it can program
>> the hardware to exit when an interrupt is ready. However I agree
>> with you that in principle we could split the apic emulation between
>> kvm and qemu, even with this featurette.
>
>Most of H/W-virtualization capable processors out there don't support
>that feature today. I think the decision (kvm or qemu) should be done
>based on performance data. I'm not worried about maintenance issues;
the
>APIC code is not expected to change frequently. I'm a bit worried about
>extra complexity caused by such split, though.
>

I had an in-kernel-apic implementation for KVM and the performance
improvement was insignificant. It is mainly a software engineering
thing.
PV drivers can benefit from APIC in the kernel but again just a mere
improvement.

>BTW, I see CPU utilization of qemu is almost always 99% in the top
>command when I run kernel build in an x86-64 Linux guest.

What does qemu do?

Idle guest hardly consume cpu, especially KVM powered.

>Jun
>---
>Intel Open Source Technology Center