Re: In kernel PIC support: kernel patch

Dong, Eddie
2007-06-25T03:32:15Z

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