Avi Kivity wrote: > 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?
GSI is ACPI notion of "Global System Interrupt". (Just parameter passing difference: GSI use GSI #, our previous discussion use: PIC/IOAPIC # + line #) > >> 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? Yes. So you mean we just add a memory Write I/F? It could be another good alternative. (I suppose MSI emulation is in kernel too if other irqchip is in kernel.) > >> 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. Yes, so basically in kernel IOAPIC has stronger reason :-) Any strong reason to support user level IOAPIC + kernel level APIC/PIC/MSI ? thx,eddie ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
