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.)
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.
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.
Any suggestion?
thanks, 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
