>> Gregory Haskins wrote: >> >> >> Hmm. If the ioapic is in the kernel, then it's a platform- wide resource >> and you would need a vm ioctl. If ioapic emulation is in userspace, >> then the ioapic logic will have decided which cpu is targeted and you >> would issue a vcpu ioctl. >> > >Thats exactly in line with my thinking.
This is one supports in-kernel apic since the physical ioapic is not bound to specific cpu. > >>> So that being said, I think the interface between userspace and kernel >would >> be no more complex than it is today. I.e. we would just be passing a >single >> int via an ioctl. >> >> I think the interface should mirror the hardware interface at the point >> of the "cut". For example, if we keep the ioapic in userspace, the >> interface is ioapic/apic bus messages. If we push the ioapic into the >> kernel, the interface describes the various ioapic pins and how the >> ioapics are connected to each other and to the processors (i.e. the >> topology). > >Agreed. I was thinking that the interface for the "IOAPIC in kernel" model >would look something like the way the pic_send_irq() function looks, except >it would also convey BUS/IOAPIC id. > Keeping the ioapic in qemu was just a temporal solution, the full blown architecture should implement everything within the kernel. ------------------------------------------------------------------------- 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
