cpu.h: Fix size of array element is not a multiple of its alignment

Pointed out by gcc11.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1937076

Change-Id: Ia76204f759710651340bc09fa6bc163d776b2ab4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3902
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

kernel/cpu: add cpu_frequency()

implement on x86 with APERFMPERF.

Change-Id: Ia484854c76dee76c5447983de15800a25d791d39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3213
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

kernel: fix missing SMP_MAX_CPUS on non-x86

* Regression introduced due to scheduler change
* Drop MAX_BOOT_CPUS as it is no longer used

kernel: Protect cpu_ent::active_time with sequential lock

atomic_{get, set}64() are problematic on architectures without 64 bit
compare and swap.
Also, using sequential lock instead of atomic access ensures that
any reads from cpu_ent::active_time won't require any writes to shared
memory.

kernel: Propagate scheduler modes to cpu{freq, idle} modules

kernel: Make get_cpu_topology() return a pointer to const

The client code is not supposed to change the topology info.
It would be also nice if cpu_topology_node::children was an array of
pointers to const but that would require several const_casts in the
topology tree generation code so it's probably not worth it.

kernel: Reduce lock contention when processing ICIs

kernel: Rework cpuidle module

* Create new interface for cpuidle modules (similar to the cpufreq
interface)
* Generic cpuidle module is no longer needed
* Fix and update Intel C-State module

kernel: Make CACHE_LINE_ALIGN visible in the whole kernel

kernel: Allow reassigning IRQs to logical processors

kernel: Measure time spent in interrupt handlers

scheduler: Minor cleanup

kernel: Add support and interface for cpufreq modules

kernel: Remove invoke_scheduler_if_idle

kernel: Create CPU topology tree

kernel: Decide whether to use simple or affine scheduler

Simple scheduler is used when we do not have to worry about cache affinity
(i.e. single core with or without SMT, multicore with all cache levels
shared).

When we replace gSchedulerLock with more fine grained locking affine
scheduler should also be chosen when logical CPU count is high (regardless
of cache).

x86[_64]: Add CPU cache topology detection for AMD and Intel CPUs

x86[_64]: Add CPU topology detection for Intel processors

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged the signals branch into trunk, with these changes:
* The team and thread kernel structures have been renamed to Team and Thread
respectively and moved into the new BKernel namespace.
* Several (kernel add-on) sources have been converted from C to C++ since
private kernel headers are included that are no longer C compatible.

Changes after merging:
* Fixed gcc 2 build (warnings mainly in the scary firewire bus manager).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40196 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed unnecessary inclusions of <boot/kernel_args.h> in private kernel
headers and respectively added includes in source files.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37259 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added cpu_ent::running_thread which is maintained by the schedulers.
* simple_smp scheduler: Rewrote the interesting part of
enqueue_in_run_queue(). It always selects a target CPU for the inserted
thread, now. If no CPU is idle, the CPU running the thread with the lowest
priority is chosen. If the thread running on the target CPU has a lower
priority than the inserted one, it will be asked to reschedule. If that's
the current CPU, we'll return the correct value (wasn't done before at
all).
These changes help reducing latencies. On my machine in an idle system
playing music DebugAnalyzer shows maximum latencies of about 1 us. I still
find that a bit much, but it's several orders of magnitude better than
before. The -j8 Haiku image build time dropped about 10%.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34635 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Reintroduced the SMP_MSG_RESCHEDULE_IF_IDLE ICI message. This time
implemented by means of an additional member in cpu_ent.
* Removed thread::keep_scheduled and the related functions. The feature
wasn't used yet and wouldn't have worked as implemented anyway.
* Resurrected an older, SMP aware version of our simple scheduler and made it
the default instead of the affine scheduler. The latter is in no state to
be used yet. It causes enormous latencies (I've seen up to 0.1s) even when
six or seven CPUs were idle at the same time, totally killing parallelism.
That's also the reason why a -j8 build was slower than a -j2. This is no
longer the case. On my machine the -j2 build takes about 10% less time now
and the -j8 build saves another 20%. The latter is not particularly
impressive (compared with Linux), but that seems to be due to lock
contention.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34615 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed the ROUNDOWN macro to ROUNDDOWN. Also changed the implementation of
ROUNDUP to use '*' and '/' -- the compiler will optimize that for powers of
two anyway and this implementation works for other numbers as well.
* The thread::fault_handler use in C[++] code was broken with gcc 4. At least
when other functions were invoked. Trying to trick the compiler wasn't a
particularly good idea anyway, since the next compiler version could break
the trick again. So the general policy is to use the fault handlers only in
assembly code where we have full control. Changed that for x86 (save for the
vm86 mode, which has a similar mechanism), but not for the other
architectures.
* Introduced fault_handler, fault_handler_stack_pointer, and fault_jump_buffer
fields in the cpu_ent structure, which must be used instead of
thread::fault_handler in the kernel debugger. Consequently user_memcpy() must
not be used in the kernel debugger either. Introduced a debug_memcpy()
instead.
* Introduced debug_call_with_fault_handler() function which calls a function
in a setjmp() and fault handler context. The architecture specific backend
arch_debug_call_with_fault_handler() has only been implemented for x86 yet.
* Introduced debug_is_kernel_memory_accessible() for use in the kernel
debugger. It determines whether a range of memory can be accessed in the
way specified. The architecture specific back end
arch_vm_translation_map_is_kernel_page_accessible() has only been implemented
for x86 yet.
* Added arch_debug_unset_current_thread() (only implemented for x86) to unset
the current thread pointer in the kernel debugger. When entering the kernel
debugger we do some basic sanity checks of the currently set thread structure
and unset it, if they fail. This allows certain commands (most importantly
the stack trace command) to avoid accessing the thread structure.
* x86: When handling a double fault, we do now install a special handler for
page faults. This allows us to gracefully catch faulting commands, even if
e.g. the thread structure is toast.

We are now in much better shape to deal with double faults. Hopefully avoiding
the triple faults that some people have been experiencing on their hardware
and ideally even allowing to use the kernel debugger normally.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32073 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed unused SMP_MSG_RESCHEDULE ICI message.
* Introduced flag "invoke_scheduler" in the per CPU structure. It is
evaluated in hardware_interrupt() (x86 only ATM).
* Introduced SMP_MSG_RESCHEDULE_IF_IDLE message, which enters the
scheduler when the CPU currently runs an idle thread.
* Don't do dprintf() "CPU x halted!" when handling a SMP_MSG_CPU_HALT
ICI message. It uses nested spinlocks and could thus potentially
deadlock itself (acquire_spinlock() processes ICI messages, so it
could already hold one of the locks). This is a pretty likely scenario
on machines with more than two CPUs, but is also possible when the
panic()ing thread holds the threads spinlock. Probably fixes #2572.
* Reworked the way the kernel debugger is entered and added a "cpu"
command that allows switching the CPU once in KDL. It is thus possible
to get a stack trace of the thread not on the panic()ing CPU.
* When a thread is added to the run queue, we do now check, if another
CPU is idle and ask it to reschedule, if it is. Before this change, the
CPU was continuing to idle until the quantum of the idle thread
expired. Speeds up the libbe.so build about 8% on my machine (haven't
tested the full Haiku image build yet).
* When spinlock debugging is enabled (DEBUG_SPINLOCKS) we also record
the spinlock acquirer on non-smp machines. Added "spinlock" debugger
command to get the info.
* Added debugger commands "ici" and "ici_message", printing info on
pending ICI message respectively on a given one.
* Process not only a single ICI message in acquire_spinlock() and other
places, but all pending ones.
* Also process ICI messages when waiting for a free one -- avoids a
potential deadlock.
* Mask out non-existing CPUs in send_multicast_ici(). panic() instead of
just returning when there's no target CPU left.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28223 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved definition of the PAUSE macro to <cpu.h>, respectively
<arch/cpu.h>.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28221 a95241bf-73f2-0310-859d-f6bbb57e9c96

yet another fix for #1018, which has at this point blossomed into a reorg of how AP cpus are initialized.
the new cpuid stuff was apparently exacerbating an existing problem where various bits of low level
cpu code (specifically get_current_cpu) weren't really initialized before being used. Changed the
order to set up a fake set of threads to point each cpu at really early in boot to make sure that at
all points in code it can get the current 'thread' and thus the current cpu.
A probably better solution would be to have dr3 point to the current cpu which would then point to the
current thread, but that has a race condition that would require an int disable, etc.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20160 a95241bf-73f2-0310-859d-f6bbb57e9c96

pulled over some stuff from newos:
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20072 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed the extra info struct in the cpu_ent union and made said union a struct instead. Same as r1137 in NewOS.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17273 a95241bf-73f2-0310-859d-f6bbb57e9c96

Reverted my last change as it turned out that the lazy FPU state handling was not SMP safe afterall and the performance gain is questionable. Maybe it'll be implemented correctly in the future. Sorry for any inconvenience this may have cost.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17272 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented lazy FPU state save/restore. In the end mostly ported from NewOS. SMP safe.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17251 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the way how CPU activity is monitored: instead of taking the active
time of the idle thread as a measure, we now compute the CPU activity on
each thread switch - the time the CPU worked is the total of user and kernel
time a thread spent during its quantum.
Unlike before, this mechanism works correctly on SMP machines. I hope this
works as expected :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16193 a95241bf-73f2-0310-859d-f6bbb57e9c96

* CPUs can now be disabled - that is, they will keep idling.
* Added syscalls _kern_set_cpu_enabled() and _kern_cpu_enabled().
* scheduler.c::sRunQueue::tail was not maintained at all; changed sRunQueue to
be a simple thread pointer instead of a struct thread_queue.
* Turns out we're monitoring CPU activity incorrectly when we've got more
than one CPU.
* Renamed the global CPU array from "cpu" to gCPU.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16186 a95241bf-73f2-0310-859d-f6bbb57e9c96

The short story: we now have MTRR support on Intel and AMD CPUs (the latter
has not yet been tested, though - I'll do this after this commit):
* Removed the arch_memory_type stuff from vm_area; since there are only 8 memory
ranges on x86, it's simply overkill. The MTRR code now remembers the area ID
and finds the MTRR that way (it could also iterate over the existing MTRRs).
* Introduced some post_modules() init functions.
* If the other x86 CPUs out there don't differ a lot, MTRR functionality might
be put back into the kernel.
* x86_write_msr() was broken, it wrote the 64 bit number with the 32 bit words
switched - it took me some time (and lots of #GPs) to figure that one out.
* Removed the macro read_ebp() and introduced a function x86_read_ebp()
(it's not really a time critical call).
* Followed the Intel docs on how to change MTRRs (symmetrically on all CPUs
with caches turned off).
* Asking for memory types will automatically change the requested length to
a power of two - note that BeOS seems to behave in the same, although that's
not really very clean.
* fixed MTRRs are ignored for now - we should make sure at least, though,
that they are identical on all CPUs (or turn them off, even though I'd
prefer the BIOS stuff to be uncacheable, which we don't enforce yet, though).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15528 a95241bf-73f2-0310-859d-f6bbb57e9c96

Preparation for MTRR support, code is completely untested, though.
The CPU specific MTRR code will be in modules.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15520 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the boot procedure a bit.
Extracted scheduler_init() from start_scheduler() (which is now called scheduler_start()).
Moved scheduler related function prototypes from thread.h to the new scheduler.h.
Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14518 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added the missing clear_caches() function and syscall. Does not yet do anything (which
is perfectly okay on x86 anyway, but should be moved into the arch stuff).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11869 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed some more init2 routines to init_post_vm() to make it clearer when
and why they are called.
Introduced a cpu_init_post_vm() that will now call arch_init_post_vm() instead
of letting main() doing it.
Fixed some return types (mostly from int to status_t).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9438 a95241bf-73f2-0310-859d-f6bbb57e9c96

Ah, that looks better (and actually works...).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@7791 a95241bf-73f2-0310-859d-f6bbb57e9c96

MAX_BOOT_CPUS is defined in kernel_args.h so we better include it.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@7790 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some header work: removed unnecessary dependencies to stage2.h, fixed
some broken C++ export definitions, added missing licenses etc.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3152 a95241bf-73f2-0310-859d-f6bbb57e9c96

beos compatible timer routines and style cleanups in timer and sem code; also doxygened timer.h


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@354 a95241bf-73f2-0310-859d-f6bbb57e9c96

It is accomplished ...


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10 a95241bf-73f2-0310-859d-f6bbb57e9c96

kernel: fix missing SMP_MAX_CPUS on non-x86

* Regression introduced due to scheduler change
* Drop MAX_BOOT_CPUS as it is no longer used

kernel: Protect cpu_ent::active_time with sequential lock

atomic_{get, set}64() are problematic on architectures without 64 bit
compare and swap.
Also, using sequential lock instead of atomic access ensures that
any reads from cpu_ent::active_time won't require any writes to shared
memory.

kernel: Propagate scheduler modes to cpu{freq, idle} modules

kernel: Make get_cpu_topology() return a pointer to const

The client code is not supposed to change the topology info.
It would be also nice if cpu_topology_node::children was an array of
pointers to const but that would require several const_casts in the
topology tree generation code so it's probably not worth it.

kernel: Reduce lock contention when processing ICIs

kernel: Rework cpuidle module

* Create new interface for cpuidle modules (similar to the cpufreq
interface)
* Generic cpuidle module is no longer needed
* Fix and update Intel C-State module

kernel: Make CACHE_LINE_ALIGN visible in the whole kernel

kernel: Allow reassigning IRQs to logical processors

kernel: Measure time spent in interrupt handlers

scheduler: Minor cleanup

kernel: Add support and interface for cpufreq modules

kernel: Remove invoke_scheduler_if_idle

kernel: Create CPU topology tree

kernel: Decide whether to use simple or affine scheduler

Simple scheduler is used when we do not have to worry about cache affinity
(i.e. single core with or without SMT, multicore with all cache levels
shared).

When we replace gSchedulerLock with more fine grained locking affine
scheduler should also be chosen when logical CPU count is high (regardless
of cache).

x86[_64]: Add CPU cache topology detection for AMD and Intel CPUs

x86[_64]: Add CPU topology detection for Intel processors

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged the signals branch into trunk, with these changes:
* The team and thread kernel structures have been renamed to Team and Thread
respectively and moved into the new BKernel namespace.
* Several (kernel add-on) sources have been converted from C to C++ since
private kernel headers are included that are no longer C compatible.

Changes after merging:
* Fixed gcc 2 build (warnings mainly in the scary firewire bus manager).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40196 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed unnecessary inclusions of <boot/kernel_args.h> in private kernel
headers and respectively added includes in source files.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37259 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added cpu_ent::running_thread which is maintained by the schedulers.
* simple_smp scheduler: Rewrote the interesting part of
enqueue_in_run_queue(). It always selects a target CPU for the inserted
thread, now. If no CPU is idle, the CPU running the thread with the lowest
priority is chosen. If the thread running on the target CPU has a lower
priority than the inserted one, it will be asked to reschedule. If that's
the current CPU, we'll return the correct value (wasn't done before at
all).
These changes help reducing latencies. On my machine in an idle system
playing music DebugAnalyzer shows maximum latencies of about 1 us. I still
find that a bit much, but it's several orders of magnitude better than
before. The -j8 Haiku image build time dropped about 10%.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34635 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Reintroduced the SMP_MSG_RESCHEDULE_IF_IDLE ICI message. This time
implemented by means of an additional member in cpu_ent.
* Removed thread::keep_scheduled and the related functions. The feature
wasn't used yet and wouldn't have worked as implemented anyway.
* Resurrected an older, SMP aware version of our simple scheduler and made it
the default instead of the affine scheduler. The latter is in no state to
be used yet. It causes enormous latencies (I've seen up to 0.1s) even when
six or seven CPUs were idle at the same time, totally killing parallelism.
That's also the reason why a -j8 build was slower than a -j2. This is no
longer the case. On my machine the -j2 build takes about 10% less time now
and the -j8 build saves another 20%. The latter is not particularly
impressive (compared with Linux), but that seems to be due to lock
contention.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34615 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed the ROUNDOWN macro to ROUNDDOWN. Also changed the implementation of
ROUNDUP to use '*' and '/' -- the compiler will optimize that for powers of
two anyway and this implementation works for other numbers as well.
* The thread::fault_handler use in C[++] code was broken with gcc 4. At least
when other functions were invoked. Trying to trick the compiler wasn't a
particularly good idea anyway, since the next compiler version could break
the trick again. So the general policy is to use the fault handlers only in
assembly code where we have full control. Changed that for x86 (save for the
vm86 mode, which has a similar mechanism), but not for the other
architectures.
* Introduced fault_handler, fault_handler_stack_pointer, and fault_jump_buffer
fields in the cpu_ent structure, which must be used instead of
thread::fault_handler in the kernel debugger. Consequently user_memcpy() must
not be used in the kernel debugger either. Introduced a debug_memcpy()
instead.
* Introduced debug_call_with_fault_handler() function which calls a function
in a setjmp() and fault handler context. The architecture specific backend
arch_debug_call_with_fault_handler() has only been implemented for x86 yet.
* Introduced debug_is_kernel_memory_accessible() for use in the kernel
debugger. It determines whether a range of memory can be accessed in the
way specified. The architecture specific back end
arch_vm_translation_map_is_kernel_page_accessible() has only been implemented
for x86 yet.
* Added arch_debug_unset_current_thread() (only implemented for x86) to unset
the current thread pointer in the kernel debugger. When entering the kernel
debugger we do some basic sanity checks of the currently set thread structure
and unset it, if they fail. This allows certain commands (most importantly
the stack trace command) to avoid accessing the thread structure.
* x86: When handling a double fault, we do now install a special handler for
page faults. This allows us to gracefully catch faulting commands, even if
e.g. the thread structure is toast.

We are now in much better shape to deal with double faults. Hopefully avoiding
the triple faults that some people have been experiencing on their hardware
and ideally even allowing to use the kernel debugger normally.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32073 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed unused SMP_MSG_RESCHEDULE ICI message.
* Introduced flag "invoke_scheduler" in the per CPU structure. It is
evaluated in hardware_interrupt() (x86 only ATM).
* Introduced SMP_MSG_RESCHEDULE_IF_IDLE message, which enters the
scheduler when the CPU currently runs an idle thread.
* Don't do dprintf() "CPU x halted!" when handling a SMP_MSG_CPU_HALT
ICI message. It uses nested spinlocks and could thus potentially
deadlock itself (acquire_spinlock() processes ICI messages, so it
could already hold one of the locks). This is a pretty likely scenario
on machines with more than two CPUs, but is also possible when the
panic()ing thread holds the threads spinlock. Probably fixes #2572.
* Reworked the way the kernel debugger is entered and added a "cpu"
command that allows switching the CPU once in KDL. It is thus possible
to get a stack trace of the thread not on the panic()ing CPU.
* When a thread is added to the run queue, we do now check, if another
CPU is idle and ask it to reschedule, if it is. Before this change, the
CPU was continuing to idle until the quantum of the idle thread
expired. Speeds up the libbe.so build about 8% on my machine (haven't
tested the full Haiku image build yet).
* When spinlock debugging is enabled (DEBUG_SPINLOCKS) we also record
the spinlock acquirer on non-smp machines. Added "spinlock" debugger
command to get the info.
* Added debugger commands "ici" and "ici_message", printing info on
pending ICI message respectively on a given one.
* Process not only a single ICI message in acquire_spinlock() and other
places, but all pending ones.
* Also process ICI messages when waiting for a free one -- avoids a
potential deadlock.
* Mask out non-existing CPUs in send_multicast_ici(). panic() instead of
just returning when there's no target CPU left.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28223 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved definition of the PAUSE macro to <cpu.h>, respectively
<arch/cpu.h>.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28221 a95241bf-73f2-0310-859d-f6bbb57e9c96

yet another fix for #1018, which has at this point blossomed into a reorg of how AP cpus are initialized.
the new cpuid stuff was apparently exacerbating an existing problem where various bits of low level
cpu code (specifically get_current_cpu) weren't really initialized before being used. Changed the
order to set up a fake set of threads to point each cpu at really early in boot to make sure that at
all points in code it can get the current 'thread' and thus the current cpu.
A probably better solution would be to have dr3 point to the current cpu which would then point to the
current thread, but that has a race condition that would require an int disable, etc.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20160 a95241bf-73f2-0310-859d-f6bbb57e9c96

pulled over some stuff from newos:
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20072 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed the extra info struct in the cpu_ent union and made said union a struct instead. Same as r1137 in NewOS.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17273 a95241bf-73f2-0310-859d-f6bbb57e9c96

Reverted my last change as it turned out that the lazy FPU state handling was not SMP safe afterall and the performance gain is questionable. Maybe it'll be implemented correctly in the future. Sorry for any inconvenience this may have cost.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17272 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented lazy FPU state save/restore. In the end mostly ported from NewOS. SMP safe.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17251 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the way how CPU activity is monitored: instead of taking the active
time of the idle thread as a measure, we now compute the CPU activity on
each thread switch - the time the CPU worked is the total of user and kernel
time a thread spent during its quantum.
Unlike before, this mechanism works correctly on SMP machines. I hope this
works as expected :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16193 a95241bf-73f2-0310-859d-f6bbb57e9c96

* CPUs can now be disabled - that is, they will keep idling.
* Added syscalls _kern_set_cpu_enabled() and _kern_cpu_enabled().
* scheduler.c::sRunQueue::tail was not maintained at all; changed sRunQueue to
be a simple thread pointer instead of a struct thread_queue.
* Turns out we're monitoring CPU activity incorrectly when we've got more
than one CPU.
* Renamed the global CPU array from "cpu" to gCPU.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16186 a95241bf-73f2-0310-859d-f6bbb57e9c96

The short story: we now have MTRR support on Intel and AMD CPUs (the latter
has not yet been tested, though - I'll do this after this commit):
* Removed the arch_memory_type stuff from vm_area; since there are only 8 memory
ranges on x86, it's simply overkill. The MTRR code now remembers the area ID
and finds the MTRR that way (it could also iterate over the existing MTRRs).
* Introduced some post_modules() init functions.
* If the other x86 CPUs out there don't differ a lot, MTRR functionality might
be put back into the kernel.
* x86_write_msr() was broken, it wrote the 64 bit number with the 32 bit words
switched - it took me some time (and lots of #GPs) to figure that one out.
* Removed the macro read_ebp() and introduced a function x86_read_ebp()
(it's not really a time critical call).
* Followed the Intel docs on how to change MTRRs (symmetrically on all CPUs
with caches turned off).
* Asking for memory types will automatically change the requested length to
a power of two - note that BeOS seems to behave in the same, although that's
not really very clean.
* fixed MTRRs are ignored for now - we should make sure at least, though,
that they are identical on all CPUs (or turn them off, even though I'd
prefer the BIOS stuff to be uncacheable, which we don't enforce yet, though).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15528 a95241bf-73f2-0310-859d-f6bbb57e9c96

Preparation for MTRR support, code is completely untested, though.
The CPU specific MTRR code will be in modules.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15520 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the boot procedure a bit.
Extracted scheduler_init() from start_scheduler() (which is now called scheduler_start()).
Moved scheduler related function prototypes from thread.h to the new scheduler.h.
Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14518 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added the missing clear_caches() function and syscall. Does not yet do anything (which
is perfectly okay on x86 anyway, but should be moved into the arch stuff).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11869 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed some more init2 routines to init_post_vm() to make it clearer when
and why they are called.
Introduced a cpu_init_post_vm() that will now call arch_init_post_vm() instead
of letting main() doing it.
Fixed some return types (mostly from int to status_t).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9438 a95241bf-73f2-0310-859d-f6bbb57e9c96

Ah, that looks better (and actually works...).


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@7791 a95241bf-73f2-0310-859d-f6bbb57e9c96

MAX_BOOT_CPUS is defined in kernel_args.h so we better include it.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@7790 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some header work: removed unnecessary dependencies to stage2.h, fixed
some broken C++ export definitions, added missing licenses etc.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3152 a95241bf-73f2-0310-859d-f6bbb57e9c96

beos compatible timer routines and style cleanups in timer and sem code; also doxygened timer.h


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@354 a95241bf-73f2-0310-859d-f6bbb57e9c96

It is accomplished ...


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10 a95241bf-73f2-0310-859d-f6bbb57e9c96