Re: KVM in-kernel APIC update

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Ingo Molnar wrote:
> we should move all the PICs into KVM proper - and that includes the 
> i8259A PIC too. Qemu-space drivers are then wired to pins on these PICs, 
> but nothing in Qemu does vector generation or vector prioritization - 
> that task is purely up to KVM. There are mixed i8259A+lapic models 
> possible too and the simplest model is to have all vector handling in 
> KVM.
>
> any 'cut' of the interface to allow both qemu and KVM generate vectors 
> is unnecessary (and harmful) complexity. The interface cut should be at 
> the 'pin' level, with Qemu raising a signal on a pin and lowering a 
> signal on a pin, but otherwise not dealing with IRQ routing and IRQ 
> vectors.
>   

Following is my view of the possible cuts:

- everything in userspace: worst performance, but needed for comaptibility

- tpr in kernel: minimal effort, bad badly defined interface

- lapic in kernel: well defined (all on-chip stuff in kernel, off-chip 
in userspace), fixes main Windows problems, interrupts still need 
userspace.  Interface is the processor's LINT pins and APIC bus.

- *pic in kernel: most effort, easiest irq synchronization.  Interface 
is pic/ioapic pin level, plus a topology description that userspace uses 
to tell the hardware how the pins are connected (logically required, but 
practically not).

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV