WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just becaus

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC
From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
Date: Tue, 16 Jun 2009 22:10:45 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Delivery-date: Tue, 16 Jun 2009 22:11:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A37F4AE.5050902@xxxxxxxx> (Jeremy Fitzhardinge's message of "Tue\, 16 Jun 2009 12\:38\:22 -0700")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A329CF8.4050502@xxxxxxxx> <m1d499yyug.fsf@xxxxxxxxxxxxxxxxx> <4A35ACB3.9040501@xxxxxxxx> <m1k53dbwo2.fsf@xxxxxxxxxxxxxxxxx> <4A36B3EC.7010004@xxxxxxxx> <m1fxe117n5.fsf@xxxxxxxxxxxxxxxxx> <4A37F4AE.5050902@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:

> The only effect of this patch is to parse the I/O APIC parts of the MADT even 
> if
> it skips the local APIC parts; it causes no change in behaviour in normal
> circumstances (unless you actually have a physical machine with ACPI and I/O
> APICs but CPUs with no local APICs, which is guess is possible in principle).

You allow getting to places like apic->setup_apic_routing without going
through prerequisites like generic_bigsmp_probe().

> Can you give an example of how mechanism and policy are mixed?  In what ways
> could it break?  Would you agree to a patch which attempts to decouple policy
> and mechanism to solve these problems?

I would agree with a patch that decouples the parts you need.  Something
that makes it possible to call apci_parse_madt_lapic_entries without
calling the rest of the code sounds reasonable.

Given that ia64 already has a separate path calling into acpi I'm not
certain there is much truly useful code that can be shared.  Getting
the BIOS bug workarounds seems reasonable.

It would be good to see at least a rough draft of where you are going.  So
the whole picture can be clear.

Right now.  I don't think there is anything in anything in
arch/x86/kernel/apic/* arch/x86/kernel/smpboot.c that is usable for xen.

As for mixing mechanism and policy besides the cpu_has_apic tests we
have generic_bigsmp_probe, the calling of apic_setup_apic_routing.
The code that depends on the CONFIG_X86_LOCAL_APIC define.

There are also deep assumptions in the code like default_setup_apic_routing.
That tests the number of local apics and uses that to decide on how to setup
the ioapics.

Eric

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>