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


I vote for the *pic in kernel:
- Clean 'cut', kills all the future arguments against moving things
around
- Easier to define a stable interface
- Easy support for PV drivers
- Easy hw assist acceleration
- Provides the best performance

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

Reply via email to