Am Wed 21 May 2008 06:41:16 PM CEST schrieb "Xu, Anthony"
<anthony.xu@xxxxxxxxx>:
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.
While the DSDT is hardcoded, the PRT entries can easily get the IRQ
Pin from the PCI configspace. Take a look at the GSI patch I sent to
the kvm ML a week ago.
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.
Right, that's exactly the problem. We should try to provide a
realistic environment, that resembles a real PC as much as possible.
This way we don't need to debug bugs in Operating Systems that would
break on unusual mainboard wirings too.
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.
So who maps which Pin to which PIC pin? What I'm saying is that you'll
have to think about that seriously.
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 about FreeBSD, Darwin, Windows NT 4? If we want to have a
virtualization solution that only works with Windows and Linux, we can
just as well use Xen PV.
So far I haven't seen any non-24-Pin IOAPICs in the wilds.
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
