Re: In kernel PIC support: kernel patch

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> 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 #)
>
>
>   

Can you refer me to any documentation about it?

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


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