Dong, Eddie wrote: > Woo, we have gone through so many threads within single day and get > almost > everything in hand now :-) Should we make a short notes on the decision > to be referenced in future (Any place to KVM I/F)? > > Basically we have solved the I/Fs issue and part IRQ delivery issue. > > Several other minor points in my mind: > > 1: Cross architecture consideration > If we want to consider other platform too such as IA64 and PPC like > that in Xen, then use GSI is better for KVM_IOAPIC_INTERRUPT. > BTW, IA64 platform doesn;t have PIC usually.(The work for IA64 is > under going.) > >
What is GSI? > 2: MSI. > Not sure if there will have requirement to support a virtual > device > with MSI support, if yes, then we may add new APIs in future. So let us > reserve some I/F for future irq injection. > We'll add it as soon as it becomes necessary. But isn't it just a memory write? > 3: IOAPIC position > Though it looks like neutral to have this one in user or kernel > space, > but I'd like to suggest we only support one model. Considering future > VT-d > case, hypervisor need to inject an IRQ directly in KVM (still thru > IOAPIC) > without going to user level, so probably moving IOAPIC to kernel is good > > in this point. > Even paravirt device drivers will want to inject IRQs via the ioapic (when the guest is not paravirt_ops enabled, like older Linux and Windows). It's probably okay to implement the device side of a block device in qemu, but more difficult for networking. If we have device implementations in the kernel then we'll need an ioapic in the kernel. Also, if we end up sharing interrupts between the kernel and userspace, we'll need the kernel to perform the OR between the level specified by the kernel devices and the level specified by userspace. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
