Clean up make targets list-arch and list-toolchain to be much faster and
work without needing to invoke the archtecture's arch rules.mk. This
should make it work on machines that do not have that particular
toolchain in the path.
This is setting up for using it in the github action script.
Require the platform or arch to provide it. The default was pretty
obsolete, assuming a 32bit arch with a split 50/50 mapping. May as well
make it a forced arch thing so that it's known to be correct.
Had to define it for OR1K, it was already defined for all the other
(known) architectures.
For newer SMP and modern cpus, just doing a full fpu context switch
is simpler and cheaper than dealing with the complexity of lazy fpu
context switch logic.
Plus this old logic was broken in the recent SMP-ification of the x86
code base. A functional version of this would be far more complex.
A large pile of changes to the PC platform and x86 architecture that
facilitate SMP support. Tested in both 64 and 32bit on qemu and real
hardware all the way back through i486.
In legacy builds it's possible to boot on a cpu that doesn't appear to
have CR4 implemented (Am586 to be precise), but there's no features
needed to set, so it seems that this was architecturally okay.
32 and 64 bit:
- For now SMAP causes the mmu unit tests to fail, so disable.
- Make sure CR4.PGE is set if present.
- Make sure the rest of the system knows that user aspaces are available
on 32bit.
- Skip cpus in the MADT table that are not enabled
- Bump count to 16 cpus
- Move the spurious interrupt vector to 0xff since it needs to end in
0xf on <=P6.
- Fix an assert in local apic code when not using x2apic and starting
secondaries.
- Follow the spec a bit closer and wait up till a second for each
secondary core to start.
-Move the local apic driver to arch/x86
-Add routines to send IPIs between cpus
Something is unstable at the moment and the system crashes after a while
with random corruptions when using SMP.
Currently only supports both set at the same time, but rearrange their
order such that theoretically both are pretty independent.
Somewhat untested in that there's no configuration for !KERNEL_VM and
WITH_SMP, but at least allows that config to be tested.
This triggered a out of range count overflow warning when
building for RV32 (calling the macro with `ticks >> 32`)
since the truncation happened before the shift.
Rearrange some of the cpu initialization code to be runnable on each cpu
as they come up. Complete the 64bit bootstrap mechanism and call into C
code.
Makes it as far as trying to reschedule via an IPI. Need to implement
local apic based IPI mechanism.
It's getting too hard to maintain a single layout that works with both,
so go ahead and split it. Also redo the layout so it should be usable
with user space and syscall and sysenter instructions from either mode.
I hadn't noticed this before, but you can directly reference a global
variable in a load/store in assembly, which combines a lla + ld/sd into
a 2 instruction pair instead of 3 due to the 12 bit offset provided in
the load/store.
This fixes a problem if the text segment gets larger than ~1MB where the
raw jal instruction cannot reach. Using 'call' or 'tail' allows the
assembler to emit a 2 instruction sequence that the linker later
relaxes if it can.
When dropping from EL2 (or EL3), load vmpidr_el2 and vpidr_el2 with the
correct values to make sure EL1 sees the 'real' mpidr_el1 and midr_el1.
Though in most cases they're already configured by whatever firmware ran
before, there's no actual guarantee that it is, and it may be full of
random garbage.
Though using the named nmemonics is a generally better idea it has the
unforunate property of not working on older compilers. In this case,
these new registers are for the Sstic extension, which is new enough
that even reasonably recent compilers as GCC 12.1 doesn't understand it.
Fixes issue #410
Sadly this doesn't really work in all situations and only happens to
work with gcc + binutils for 32bit accesses, presumably because gnu as
replaces a literal 0 with wzr.
Clang doesn't understand it at all.
This reverts commit 6c14941dec.
When dumping_mode_regs() on a fault, avoid printing the stack beyond the
current page. This prevents exceeding the stack base and hitting a
guard page in the case the stack use is < 128 bytes.
Bug: 336957655
Test: crash test, observe double fault fixed
Change-Id: If49b5fe5e1651557d19bf18c4026224cfb038101
For older compilers (gcc 7.5.0 in particular) avoid using
-mgeneral-regs-only to override the floating point switches, since it
doesn't seem to understand that switch.
Instead more properly add the floating point switches for a module or
source file compiled with float. More compatible with all compilers.
Was already added to arm64, but arch/arm hadn't picked up this feature
yet. Uncovered a few places here or there that wasn't marking code as
float/no-float, but this fixes a problem where newer compilers are
starting to sneak in vector code because they can.
Issue #406
To work properly with some hypervisors on various architectures (ARM,
ARM64, x86), add global routines to allow access to MMIO registers via
architecturally defined accessors.
Add accessors for ARM, ARM64, and x86-32/64. Have the other arches
default to just using whatever the compiler emits.
Will need to generally move things off the legacy REG*() accessors
since they're really not safe going forward with what compilers emit.
