[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC
[Jeremy Fitzhardinge - Fri, Jun 12, 2009 at 11:22:48AM -0700] > Parse the ACPI MADT for I/O APIC information, even if the cpu has no > (apparent) local APIC (ie, the CPU's APIC feature flag is clear). > > In principle, the local APIC and the I/O APIC are distinct (but related) > components, which can be independently present. > > In practice this can happen in a Xen system, where the hypervisor has > full control over the local APICs, and delivers interrupts initiated by > the I/O APICs via Xen's event channel mechanism. > > (This eliminates the need for any explicit if (xen...) tests in > acpi/boot.c) > > Signed-off-by: Jeremy Fitzhardinge<jeremy.fitzhardinge@xxxxxxxxxx> > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c > index 2410469..19d13e5 100644 > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -193,9 +193,6 @@ static int __init acpi_parse_madt(struct > acpi_table_header *table) > { > struct acpi_table_madt *madt = NULL; > > - if (!cpu_has_apic) > - return -EINVAL; > - Hi Jeremy, just for the record -- this removement has a side effect. Imagine I've passed "disableapic" so I expect as many as possible apic-related code would not pass thru execution. Now we would have (say for IBM Summit) acpi_parse_madt default_acpi_madt_oem_check summit_acpi_madt_oem_check mark_tsc_unstable setup_summit Dunno if it harmless or no but it changes kernel behaviour. cpu_has_apic cleared if disableapic option (which is early param) passed to kernel. Just a note. Didn't walk thru all ways. -- Cyrill _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |