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

Re: [Xen-devel] nr_irqs_gsi



On 07/23/12 23:34, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 23, 2012 at 02:30:37PM +0100, Jan Beulich wrote:
>>>>> On 12.07.12 at 04:17, Joe Jin <joe.jin@xxxxxxxxxx> wrote:
>>>>>> (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
>>>>>> (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
>>>>>> (XEN) ACPI: IOAPIC (id[0x01] address[0xfec80000] gsi_base[32])
>>>>>> (XEN) IOAPIC[1]: apic_id 1, version 32, address 0xfec80000, GSI 32-55
>>>
>>> Below came from dom0:
>>>
>>> ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
>>> ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
>>> IOAPIC[0]: apic_id 0, version 255, address 0xfec00000, GSI 0-255
>>
>> Now this and ...
>>
>>> ACPI: IOAPIC (id[0x01] address[0xfec80000] gsi_base[32])
>>> IOAPIC[1]: apic_id 1, version 255, address 0xfec80000, GSI 32-287
>>
>> ... this is clearly bogus, contradicting what Xen itself prints (see
>> above).
> 
> Yeah, that got fixed up in v3.5 (merge git 
> f08b9c2f8af0d61faa1170aeae4fbca1eff6a504)
> specifically:
> 
>       x86/apic: Fix UP boot crash
>       xen/apic: implement io apic read with hypercall
>       xen/x86: Implement x86_apic_ops
>       x86/apic: Replace io_apic_ops with x86_io_apic_ops.
>       x86/ioapic: Add io_apic_ops driver layer to allow interception
> 

Konrad,

Would you please point out which commit is make sense for this issue? so far I 
still
suspend it's a hypervisor issue rather than dom0 kernel.

Thanks in advance,
Joe


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.