RE: [Xen-devel] Re: APIC rework

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>> 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