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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
