[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: APIC rework
>> And if we remove ioapic >> logic from dom0, we need to find new way how to setup GSI irq. And >> this patch comes out under this situation. > > Why does this need to be done under dom0 control? All GSIs are > parseable by Xen by itself aren't they, from MPBIOS tables or ACPI > MADT? So > at least Xen > should be able to work out for itself APIC pin -> GSI > mappings, and pol/trig > settings. My 2 cents for this topic, although I'm still trying to figure out the whole picture of the patch and discussion thread. The ACPI MADT table gives the relationship between IOAPIC and gsi, while DSDT table's _PRT gives the relationship between PCI devices and GSI. Two way provided in ACPI _PRT table. If the source filed in _PRT entry does not refert to any device, it means a GSI. I didn't find any hint in ACPI spec on the polarity/level should be configured. Currently kernel assume the polarity/level is fixed as low/level, which I suspect is according to PCI spec. If the _PRT table present the interrupt as PCI Interrupt Link Device, that means the interrupt attribute is configurable, OSPM need figure out the polarity/level information through _CRS/_PRS method in these objectes. For method 1 (i.e. source filed does not refer to device), maybe we can assume the attribute is fixed and Keir's suggestion will work, while I suspect if Xen can do anyting for second type. Quickly check Xiantao's patch, I suspect if it will work for 2nd situation. BTW, I don't know know any system which use 2nd type when working in APIC mode. --jyh _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |