Messages in this thread | | | Date | Sat, 13 Jun 2009 00:11:17 +0400 | From | Cyrill Gorcunov <> | Subject | 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@citrix.com> > > 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
| |