Re: KVM in-kernel APIC update

[Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:

> > My current thoughts are that we at least move the IOAPIC into the 
> > kernel as well.  That will give sufficient control to generate ISA 
> > bus interrupts for guests that understand APICs.  If we want to be 
> > able to generate ISA interrupts for legacy guests which talk to the 
> > 8259s that will prove to be insufficient.  The good news is that 
> > moving the 8259s down as well is probably not a huge deal either, 
> > especially since I have already prepped the usermode side.  
> > Thoughts?
> 
> I would avoid moving down anything that's not strictly necessary.  If 
> we want to keep the PIC in qemu, for example, just export the APIC-PIC 
> interface to qemu.

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.

	Ingo

-------------------------------------------------------------------------
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