- 17 Apr, 2008 40 commits
-
-
Glauber de Oliveira Costa authored
it is a little bit more complicated than x86_64 due to erratas and other stuff, but its existance will ease integration Signed-off-by:
Glauber Costa <gcosta@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
We introduce empty macros just to make them look like the same Signed-off-by:
-
Glauber de Oliveira Costa authored
We can do it now that do_boot_cpu has its own worker. Signed-off-by:
-
Glauber de Oliveira Costa authored
Use a new worker, with help of the create_idle struct to fork the idle thread. We now have two workers, the first of them triggered by __smp_prepare_cpu. But the later is going away soon. Signed-off-by:
-
Glauber de Oliveira Costa authored
As we now boot cpus from cpu_up, we don't need it. Signed-off-by:
-
Glauber de Oliveira Costa authored
After all the infrastructure work, we're now prepared to boot the cpus from cpu_up, and not from prepare_cpus. So the difference between cold boot and hotplug is effectively over, and the functions are used to the purposes they're meant to. Signed-off-by:
-
Glauber de Oliveira Costa authored
It was okay when cpus were cold booted before this point. But with the new state machine, they will not have arrived to the trampoline yet. zapping low mappings will have the bad effect of breaking it completely after paging enablement Signed-off-by:
-
Glauber de Oliveira Costa authored
Only call schedule_work if keventd is already running. This is already the way x86_64 does Signed-off-by:
-
Glauber de Oliveira Costa authored
it is redundant, since it is already done by set_cpu_sibling_map() Signed-off-by:
-
Glauber de Oliveira Costa authored
this does not exist, so it will be an empty macro Signed-off-by:
-
Glauber de Oliveira Costa authored
With this, remove its late_initcall marker from nmi_32.c Signed-off-by:
-
Glauber de Oliveira Costa authored
Two more files goes away. nmi_64.h and nmi_32.h gives birth to nmi.h Signed-off-by:
-
Glauber de Oliveira Costa authored
use mach_traps when it is supposed to be used. Signed-off-by:
-
Glauber de Oliveira Costa authored
By this time, they are already set in init routines Signed-off-by:
-
Glauber de Oliveira Costa authored
We move it to apic_32.c, since it's irq related anyway, and only called from that file. Signed-off-by:
-
Glauber de Oliveira Costa authored
We do it and also fix conflicts, which makes x86_64 automatically closer to i386 Signed-off-by:
-
Glauber de Oliveira Costa authored
Do it and also fix conflicts, which automatically makes x86_64 look closer to i386 Signed-off-by:
-
Glauber de Oliveira Costa authored
this patch allows x86_64 to use subarch mach_ headers in practice, since x86_64 does not have any subarch, it will use mach_default. But it will allow for substantially less code duplication Signed-off-by:
-
Glauber de Oliveira Costa authored
the cpu count is changed accordingly: now, what matters is online cpus. Also, we add those functions for x86_64 Signed-off-by:
-
Glauber de Oliveira Costa authored
It will ease integration for x86_64 Signed-off-by:
-
Glauber de Oliveira Costa authored
Impressing friends is a very important thing. Do it in a separate function to make it even more explicit, and ease integration. Signed-off-by:
-
Glauber de Oliveira Costa authored
weighting a map will do. Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
Glauber de Oliveira Costa authored
This is the way x86_64 does, and complement the already present patch that does the bios cpu to apicid mapping here Signed-off-by:
-
Glauber de Oliveira Costa authored
We fill the per-cpu (or array) that maps bios cpu id to apicid in mpparse_32.c, the way x86_64 does Signed-off-by:
-
Glauber de Oliveira Costa authored
We use the same routing as x86_64, moved now to setup.c. Just with a few ifdefs inside. Note that this routing uses prefill_possible_map(). It has the very nice side effect of allowing hotplugging of cpus that are marked as present but disabled by acpi bios. Signed-off-by:
-
Glauber de Oliveira Costa authored
missing a semicolon Signed-off-by:
-
Glauber de Oliveira Costa authored
Instead of declaring them inside of X86_64 ifdef, do it unconditionally Signed-off-by:
-
Glauber de Oliveira Costa authored
this will serve as a reference as to whether or not to use the per_cpu variables in mpparse. Done the same way as x86_64 Signed-off-by:
-
Glauber de Oliveira Costa authored
This mapping already exists in x86_64, just provide it for i386 Signed-off-by:
-
Glauber de Oliveira Costa authored
take them off smp_{32,64}.h and move to smp.h Signed-off-by: -
Glauber de Oliveira Costa authored
Done to match x86_64 Signed-off-by:
-
Glauber de Oliveira Costa authored
We have already removed the only condition that could fail here. so just don't test for any return value Signed-off-by:
-
Glauber de Oliveira Costa authored
Do tests before do_boot_cpu in native_cpu_up for i386. Tests are a little bit broader than originally, and are the same as x86_64. Test for smp_callin is not applicable right now and is deferred. Signed-off-by:
-
Glauber de Oliveira Costa authored
Put it in a disable_smp() function, as x86_64 does Signed-off-by:
-
Glauber de Oliveira Costa authored
Isolate all sanity checking in a smp_sanity_check() function as x86_64 does. Signed-off-by:
-
Glauber de Oliveira Costa authored
goal is to have i386 and x86_64 closer, so we add barriers to match Signed-off-by:
-
Glauber de Oliveira Costa authored
This patch does not change the behaviour of x86_64, since APIC_INTEGRATED is always defined as (1). But the code now matches exactly i386 version (well, this part of the code, at least) Signed-off-by:
-
Glauber de Oliveira Costa authored
it is always integrated, so define as 1. Signed-off-by:
-
Glauber de Oliveira Costa authored
it does not need to be inside lock. Do the way i386 does. Signed-off-by:
-
