[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


  • To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  • From: Cyrill Gorcunov <gorcunov@xxxxxxxxx>
  • Date: Sat, 13 Jun 2009 00:11:17 +0400
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 16 Jun 2009 04:21:54 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=d/eW8l9R+HDGtQCJ6dK9P/AeJZvYsJpwZmpYR9kovHhv9+3TMzsViga7g556/f9hpj njqg1zYBfICo0xquCTJmgBq5Az25kheNr9CBlzGfmD4RsJiz3rYWJgKfiJqK75waWE14 qYq5JiX+OzJ1ocLFo52ck/UvRC3VTu/FPBePw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

[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


 


Rackspace

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