* Avi Kivity <[EMAIL PROTECTED]> 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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
