Re: [PATCH] kvm-ia64 irq assignment 1/2 kernel

Alexander Graf
2008-06-10T07:25:46Z

On Jun 10, 2008, at 8:33 AM, Xu, Anthony wrote:

> Avi Kivity wrote:
>>
>> I suggest modifying the firmware to report the interrupts as active
>> high. Since Xen does not emulate polarity, the change will not
>> affect
>> it and the firmware can continue to be shared. I'd also recommend
>> fixing Xen to emulate the polarity correctly, if possible.
>
> Thanks for your comments
> I agree modifying common code is not a good method.
>
> While your suggestion seems be infeasible too.
> According to acpi spec, only irq <=15 can be configured, such as
> trigger
> level, polarity.
> For irq >15 , means connect to IOAPIC directly, it can't be
> configured,
> it must be level triger, active low.
>
> I can't find any mechanism in firmware to configure irqs (> 15).
> Please
> enlighten me if you have.

You can change the defaults on that IOAPIC-wise. IIRC this was in the
MADT, but I'd have to check.

> From some experimental, Firmware both in IA64 and IA32 doesn't program
> IOAPIC,
> It's Guest OS to program.
> Guest OS gets PRT first,
> If the PCI device connected to IOAPIC pin directly, looks like below
> /* Device 1, INTA - INTD */
> Package(){0x0001ffff, 0, 0, 20},
> Package(){0x0001ffff, 1, 0, 21},
> Package(){0x0001ffff, 2, 0, 22},
> Package(){0x0001ffff, 3, 0, 23},
> Guest OS configures this IOAPIC pin with level triger, active low
> unconditionally.

Yes, the Guest OS reads the PRT and configures the IOAPIC and LAPIC
accordingly.

> If the PCI device connected to IOAPIC pin through interrupt link, the
> irq attribute(level, polarity) is decided by interrupt link attribute,
> Below is the interrupt link attribute in kvm/ia32
> Device(LNKA){
> Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
> Name(_UID, 1)
> Name(_PRS, ResourceTemplate(){
> Interrupt (, Level, ActiveHigh, Shared)
> { 5, 10, 11 }
> })
> It's defined as level trigger, activehigh, that's the reason why pci
> device worked well in kvm/ia32.

This is the what I call "Legacy" way of handling interrupt lanes.
Usually nowadays you simply connect devices magically to IOAPIC pins,
which is exactly what you showed in the previous section. This "new"
behavior is usually activated when the OS calls the _PIC function in
the DSDT with a parameter != 0.

> I think below scheme is feasible,
> 1. all PCI devices in Qemu uses level trigger, active low interrupt.
> (not include ide, even though it is a PCI device, it uses legacy
> interrupt mechanism)

This is what the PCI spec requires anyway. The way it's done right now
looks wrong to me.

> 2. in Guest Firmware, all PCI devices' interrupts are configured as
> level trigger, active low
> for KVM/IA32 Guest firmware, just a little modifications
> Name(_PRS, ResourceTemplate(){
> Interrupt (, Level, ActiveHigh, Shared)-->
> Interrupt
> (, Level, ActiveLow, Shared)

While at it it might be a good idea to switch to the direct IOAPIC-
mapping approach. I sent a patch that did this on the kvm list some
time ago. Please consider reading that and tell me what you think of
it. It apparently broke Windows, but that might be simply an issue of
the wrong ActiveHigh/ActiveLow configuration.

> There are some modifications in Qemu, But I think it's a worthwhile,
> it's a thoroghly solution both for KVM/IA32 and KVM/IA64.

In essence this sounds great to me! I would love if we could talk
about this on the KVM Forum.

Thank you,

Alex