- 17 4月, 2008 40 次提交
-
-
This is to match i386. The former name was cuter, but the current is more meaningful and more general, since cpu_id can be a logical id. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
voyager would conflict with it, but the types are ultimately compatible. So remove the extern definition from voyager_smp.c in favour of the common one Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
Move map_cpu_to_logical_apicid() and unmap_cpu_to_logical_apicid() to smpboot.c. They take together all the bunch of static functions they rely upon Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
Now that we boot cpus here, callin_map has this meaning (same as x86_64) Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
wakeup_secondary_via_INIT => wakeup_secondary_cpu. This is to match i386, where init is not always used. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
After the inclusion, a lot of files needs fixing for conflicts, some of them in the headers themselves, to accomodate for both i386 and x86_64 versions. [ mingo@elte.hu: build fix ] Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
We don't need __smp_prepare_cpu anymore. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
This patch provides minor adjustments for do_boot_cpus in both architectures to allow for integration Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
We do it to make it close to x86_64. The later needs it, otherwise the nmi watchdog can get into the scene and kill us with a hammer. Enabling irqs here used to trigger a bug in i386. This is because time irq handling relies upon structures that are only initialized after smp initcalls (More precisely, it will find per_cpu(hrtimer_bases, cpu)->cb_pending list not initialized and crash) Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
It splits setup_local_APIC in two, providing a function corresponding to the ending part of it. As a side effect, smp_callin looks the same between i386 and x86_64. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
We introduce empty macros just to make them look like the same Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
We can do it now that do_boot_cpu has its own worker. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
As we now boot cpus from cpu_up, we don't need it. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
Only call schedule_work if keventd is already running. This is already the way x86_64 does Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
it is redundant, since it is already done by set_cpu_sibling_map() Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
this does not exist, so it will be an empty macro Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
With this, remove its late_initcall marker from nmi_32.c Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
Two more files goes away. nmi_64.h and nmi_32.h gives birth to nmi.h Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
use mach_traps when it is supposed to be used. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
By this time, they are already set in init routines Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
We move it to apic_32.c, since it's irq related anyway, and only called from that file. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
We do it and also fix conflicts, which makes x86_64 automatically closer to i386 Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
Do it and also fix conflicts, which automatically makes x86_64 look closer to i386 Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
the cpu count is changed accordingly: now, what matters is online cpus. Also, we add those functions for x86_64 Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
It will ease integration for x86_64 Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
weighting a map will do. Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ingo Molnar 提交于
Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
missing a semicolon Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
Instead of declaring them inside of X86_64 ifdef, do it unconditionally Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
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: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
This mapping already exists in x86_64, just provide it for i386 Signed-off-by: NGlauber Costa <gcosta@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-