Similar to open firmware implementation.
This allows to load the kernel from a remote_disk_server.
IP address is recovered using LoadOptions with a syntax similar to the
Linux kernel network boot "ip" parameter. If this is not set, no network
booting is attempted, in order to not slow down normal booting by
waiting on network traffic.
Change-Id: I17738bbcde85921672965b9936a2b484f1e57c6c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3678
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
The uart virtual address changes as soon as we apply the kernel memory
map. gUART is used only after that, from serial_init() onwards. So it
should use the virtual address, and not the physical address it was
previously created with while parsing the FDT.
Change-Id: I8c8a024fe564b49d6555f8e48f5ab31652d30708
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10068
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
They're not needed anymore. The VMTranslationMap method was confusingly
named anyway, as the other Debug* methods are for use in KDL, while
this one required the regular locks and flush mechanisms.
Change-Id: Ic1baf3d786071562d8beaeb768d996cd1d34f9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9706
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* prefer v3 over v2
* adding efi attributes in gBootVolume KMessage is a bit of a hack, but
shouldn't hurt older kernels.
Change-Id: If5ea19dafa5a845872eb8d577e77a6935539ce20
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9685
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested by OscarL and confirmed to be working on at least
one machine, though on others it hangs, so leaving out
of the default builds for now.
This adds an "acpi_processor_id" field to x86 arch_cpu_info,
gleaned from the MADT, so we can match our cpu_ents to ACPI
processor objects. (FreeBSD does a similar mapping, see
their acpi_cpu_probe method.)
Change-Id: Idb5e3c1fc1efaa4256d60ea17dd1824345369687
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9637
Reviewed-by: waddlesplash <[email protected]>
This should make use-after-frees more likely to be caught by the
standard paranoia facilities (and make them less likely to be
exploitable as memory will take longer to be reused.)
These instructions are only available on more recent CPUs (MWAITX
on AMD since around 2015 or so, TPAUSE on Intel since around 2020.)
They allow idly waiting on the TSC even when interrupts are
disabled.
Most hypervisors do not have these available (KVM does provide
them, though not on all configurations), but on bare metal this
should make a nice difference to KDL power consumption: I tested
with a Ryzen 3700X, according to my UPS (so including monitor
and peripherals) the system used ~106 W at idle, 160 W in KDL
before this patch, and 125 W in KDL after it.
Change-Id: Id7a22ecd33f3fc005b2c312f945dc3cd364e96fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9604
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The idea is to add a facility that will use less CPU than
the loops we currently use. The default implementation just
calls spin(), which is rdtsc+pause. This already may save
some power compared to what we previously did, which was to
re-check serial ports, PS/2, etc. every single loop in
the debugger, broken up only by "pause".
Change-Id: Ie421adae5c25ad6ae0c266d1d28c2ea7b81ae465
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9603
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This massively cuts down on lock contention in Add(), since insertions
only acquire a write-lock in the case where a generation rolls over,
same as Lookup() does.
"git status" in buildtools, cold disk cache in a 4-core VM, seems about
the same, maybe slightly slower (~0.5s seemed typical, out of 20-21s),
while with a hot disk cache it's much faster: ~9.8s -> ~2.4s. Compile
performance seemed about the same.
Change-Id: Ia73f35fbbad3b3ac9ed783ea38cb8e2cb9818b5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9580
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
x86_64 already does this and it seems to work fine. Since stack areas
grow downwards and should always have a guard page, overruns shouldn't
be too much of a concern (for that matter, randomization still makes
a difference here also, it seems.)
This allows us to regain another ~256 MB or so of contiguous address
space (areas smaller than that could still be inserted in the 0x6.. to
0x7.. block, but if you had 10MB of free address space below 0x6..,
and 246MB above it, you couldn't allocate a 256MB block.)
Part of #19592.
The openboot mmu code does not like addresses above 4GB, so load the
kernel to a lower address. It doesn't really matter anyway, because on
sparc the kernel normally lives in a separate address space and uses
special instructions to access userland memory.
See #19597 for details, further changes will be needed here.
Change-Id: Iac6901f275667efef5e64d059daf4c96032a7baf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3573
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
See inline comment: otherwise we could deadlock waiting for busy pages.
At the same time, make page_faults_allowed just an int16 and drop
atomics and extra checks, they aren't needed.
Fixes#19441.
Change-Id: I1b7cc06f66b44c3520fa36497c076ee5a6320706
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9120
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It's needed by GCC2 stdc++, but we shouldn't be including it
for all consumers of <stdio.h>, which we were. Drop it,
and adjust all the things that were relying on <stdio_pre.h>'s
definition of __PRINTFLIKE to use the _PRINTFLIKE defined
in BeBuild.h instead.
Hopefully should not cause any breakage; the libroot
implementation of __freading depended on this, but
I didn't see anything else which did.
"int" of course is also an abbrevation for "integer", so having
two abbreviations is sometimes confusing. The BeOS functions
just use "interrupt" (e.g. "install_io_interrupt_handler"); it
seems we inherited the "int" abbreviation from NewOS.
The basic kernel methods and files related to interrupts are
here adjusted to drop the abbreviation and just use "interrupt(s)".
The architecture-specific functions ("arch_int_*") are mostly
moment left alone for now, though of course architecture-specific
usages of the generic kernel methods are adjusted.
Change-Id: Ic113ea1280a3c78e25f8ca3cc55b24ed5f594eae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9119
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The XSAVE area can be quite large (1-2KB+), so rather than always
putting it on the kernel stack, just use the arch_thread FPU state.
Change-Id: Ie64c3ea3ca52cd8a4425ae1da69792588a69832a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9090
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This reverts most of c7360f4b02.
Unlike the other floating-point registers, these values are callee-saved
(see "System V Application Binary Interface, AMD64 Architecture
Supplement" section 3.2.1.) So we need to preserve their values and not
reset defaults on context switch.
EMMS, as the previous changes used, does not suffice to clear
exceptions. We could use FNCLEX instead, but we need to reset
x87 state on context switch anyway, so use FNINIT. Do not
reinstate FNCLEX in the exception handler since it will
be executed on context switch anyway.
We also need to ensure a clean initial state, so take care of that
in arch_thread_init.
See also:
* remarks in 396b74228e
* as well as 53e2dc0f85Fixes#19454 and #18624. Doesn't regress #18656 and #19063.
Doesn't seem to affect #19450.
Change-Id: I7179f1ec7304e7aed09ff80f6773e53d5dbdf5f9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9081
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This cleans up a lot of subtle or hidden inconsistencies:
* Drop the "exactAddress" parameter. It was added in hrev15708 (2005),
but all callers in all bootloaders passed "false" to it until 2022,
when one codepath in the ARM32 EFI loader started using it.
* Adjust EFI's platform_allocate_lomem to platform_allocate_region_below,
and add a platform_assign_kernel_address_for_region(). This allows the
aforementioned ARM EFI codepath to continue to do what it wants,
which is to get an identity-mapped trampoline page, without having
functions with confusingly different semantics ("allocate_lomem"
assigned the virtual addresses as identity-mapped unconditionally,
but it didn't insert these into the virtual allocated ranges.)
This also paves the way for other EFI loaders to use this method
to allocate memory below whatever default the boot services
would give us.
* Drop fixed virtual address allocation for all arches on EFI, with the
exception of fixed addresses inside KERNEL_LOAD_BASE, same as on
other boot platforms. Anything which wants fixed virtual addresses
outside that region can use the new "assign kernel address" method.
* Validate kernel base and size against kMaxKernelSize, instead of
assuming it fits. This matches behavior of other boot platforms.
Ideally we would have some more generic routine for mapping the
kernel, but this suffices for now.
Tested with x86_64 and ARM; both still boot (well, ARM boots as
far as it did before this commit, anyway.)
Change-Id: Ieb4fba752994101191a2335cb5395eb2b726fcbb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9024
Reviewed-by: waddlesplash <[email protected]>
We use the TSC to measure the APIC frequency, but the TSC frequency
is only fully initialized in the kernel (where it's read from CPUID
on recent hardware).
Furthermore, on some more recent systems, it seems there may only be
X2APIC and no MMIO APIC timer at all, and the bootloader does not
handle that case.
The method in the kernel uses spin() instead of a fixed instruction
count as well as system_time_nsecs() and a double for (hopefully)
more accurate calibration.
At least on VMware, this method seems more accurate: the APIC frequency
read from the hypervisor CPUID leaf is 66,000,000; the old method in
in the bootloader yielded values like "65,801,075" and "65,106,382",
while the new one yields values like "65,963,920" and "65,962,580"
(those pairs of values are from two consecutive boots.)
The difference was sometimes similar (but smaller as a percentage) in
QEMU with software emulation: e.g. "993,218,085" vs. "992,965,761". But
sometimes it wasn't: e.g "991,619,585" vs. "993,689,669". (QEMU in
software mode doesn't report a frequency via hypervisor CPUID leaf.)
Change-Id: I4fb8535d1d984f13867e2f84e7dfad1ceed42c13
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8999
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
We always did under EFI but not under BIOS. Now, the BIOS loader
reports the root pointer as well, so we don't need to find it again.
Change-Id: Ie83adb53f098d44f2688a1a327c084f94afa2673
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8941
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This solves a TODO for reporting CoW counts in area_info, and paves
the way for adaptive handling of pre-faulting based on how many
faults a cache has handled.
Change-Id: I4ecd7cf46b794c51acac87184fef49ea5ce76743
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8873
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* alignment, cookie, constructor, destructor are rarely used
(in fact constructors/destructors are never used at present.)
* Add flags argument, this is more commonly used.
This allows a lot of the invocations of create_object_cache_etc
to be changed to invocations of just create_object_cache, simplifying
the code significantly.
It checks whether the page or page's data is present in an underlying
"backing store", not whether the page is present in the cache itself.
No functional change intended.
This solves some TODOs and allows image_debug_lookup_user_symbol_address
to be dropped entirely. It should also fix reading symbols from binaries
that have multiple TEXT regions, and most functions are not in the first.
Jérôme Duval