RE: [kvm-ia64-devel] IRQ assignment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexander Graf wrote:
> On May 21, 2008, at 6:07 PM, Xu, Anthony wrote:
>> 
>> Thanks for your support, I preper option #1,
>> Any suggestion for the mapping from BDF to irq.
>> 
>> In XEN both in IA64/IA32,
>> 
>> BIOS provides a 48 pin IOAPIC ( usually it is 24) to reduce irq
>> sharing.
> 
> Most mainboards these days provide two IOAPICs, which would sum up to
> 48 again. I think that should be the preferred way of implementing it
> virtually too.
You must refer to high end server.
I think, in destop and volume server, there is one IOAPIC.
It is a little complex to provide two IOAPICs.

We may need to add algorithm in qemu on how to assign pci device irq to
different IOAPIC.

Current DSDT in guest BIOS is hardcoded, that means pci device interrupt
route is fixed.
While it is qemu to emulate the whole platform, maybe letting qemu to
dynamic to build DSDT is a nice method.




> 
>> 
>> 0~15 are reserved for legacy devices.
> 
> This is because the old PIC controllers handled up to IRQ16
> 
>> 
>> Pci devices use 16~47,
> 
> IIRC on most real machines Pins 16-20 are used for LNKA to LNKD.
It's true in some machine,
But pci device can use 16~47 if matherboard designer will.



> 
>> 
>> The mapping is like
>>  ((bdf >> 3) *4) %(48-16) + 16
>> Means every pci interrup pin( irqA, irqB, irqC, irqD) of every pci
>> device use different irq pin of IOAPIC if number of pci devices is
>> less than 8.
>> I think it can avoid interrupt sharing in most case.
>> 
>> If use this method, we can share same IA64 guest BIOS between
>> XEN/IA64 and KVM/IA64.
> 
> I'm not sure if I'm too fond of that method. It does not look too
> compliant with how PCs work these days. You might want to use that
> formula on the second IOAPIC only, so all PCI devices get routed to
> pins 25-48. Remember that you still have to provide "legacy boot
> interrupts" that map these to the first IOAPIC for Operating Systems
> that don't know how to handle high pin interrupts.
In legacy boot, PIC is used, there is no issue.



> 
> I am not sure which OSs that would be, but I'm pretty sure all the
> PCIe PCI-bridge vendors didn't implement that feature for nothing.
>From IOAPIC spec,  pin number is not fixed, OS needs to get the pin
number first from ACPI.
XEN have been using virtual 48 pin IOAPIC for a while, it works well,
both windows and linux recoginize 48-pin IOAPIC.



> 
>> 
>> 
>> 
>> What do you think?
> 
> The idea is great! I tried extending the IRQ logic to a "full IOAPIC"
> myself recently, but failed miserably. The biggest hurdle is that
> currently the code is reversed in qemu. If an interrupt occurs, the
> PIC is asked if it's destined to go there and if not it gets rerouted
> to the IOAPIC. Unfortunately this breaks with IRQs > 16.
> 
> I'll attach a small C program we developed internally to read out the
> IOAPIC from within Linux. You could try to run that on your machine to
> see how your IOAPIC is configured. One more good idea would be to get
> yourself a machine with PCI Express cards. Those handle IRQs pretty
> much the way you want them to be.
> 
> Regards,
> 
> Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux KVM Devel]     [Linux Virtualization]     [Big List of Linux Books]     [Linux SCSI]     [Yosemite Forum]

  Powered by Linux