Re: In kernel PIC support: kernel patch

Dong, Eddie wrote:

Avi Kivity wrote:
  

quoted

Dong, Eddie wrote:
    

quoted

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


  

Can you refer me to any documentation about it?

quoted

quoted

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

We already have kernel->user write (normal mmio)
If both the interrupt originator and the irqchip are in the kernel there 
is no need for an api.
So all that is left is an mmio api from user to kernel.  Which makes 
sense: if we have memory resources in the kernel, we need to be able to 
access them from userspace (one example already exists, RAM, which is 
accessed in userspace through mmap()).

quoted

quoted

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 ?
  

No strong reason.  It may be desirable for debuggability, but not much else.

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