Change-Id: Id43bfcbfc24b1adb8f6e9fff587c6df9b62910f2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2413
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous version of the patch was broken by the EFI refactoring.
Change-Id: I6dd125100b22b2461c531bfd8f81b3dd28e2b751
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2409
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
It is no longer an error to destroy a ConditionVariableEntry
that is still attached to a ConditionVariable; it will
now be implicitly detached in that case.
This makes ConditionVariableEntrys much eaiser to use
from an API standpoint.
Change-Id: I03c676d3a198aa885de733d3e1729b15f80de031
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2301
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I0d6d2f8db2bc86c08d5ba2648f1cf46d85b54a5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2267
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* arm efi additions
* cleanup some cpu headers which were oddly
split between efi and bios_ia32
* Move calculate_cpu_conversion_factor over to
arch_timer since it is timerish, and x86 only
* Drop some duplicated code from efi start. Move
hpet init code into efi timer/hpet code
Change-Id: Ia4264a5690ba8c09417b06788febc4f572f111ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2259
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This is the bulk of the work. Anything else should be
minor cleanups and tweaking.
* riscv64 isn't a viable EFI platform yet.. just acting
as a stand-in to test a non-x86 EFI haiku_loader
Change-Id: Ib03de81e2b562e693987b86d7b4318209fb1c792
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2256
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
On modern x86, one can use __rdtscp to get the current cpu in userland.
Change-Id: I1767e379606230a75e4622637c7a5aed9cdf9ab0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2248
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The hacks to still use actual system headers for zlib didn't quite work.
- Define Z_SOLO, which makes zlib build without any system include
- Remove use of std::max and #include <algorithm> from AVLTree
- Do not include DebugSupport.h because it uses system headers
- Do not include uuid.h and define just what we need
Now it's possible to compile the btrfs_shell on Linux.
Change-Id: I74a14b5f6804db45ab5a9f582ab493d696376fd3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2098
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This issue was initially detected by PVS Studio (issue number V547) and fixed
as part of Google Code-in 2019.
The initial problem was the calculate_cpu_conversion_factor function
which had been copied in the BIOS and EFI versions of the boot code.
Further investigation led to more duplicated or very similar functions
being identified.
Introduce an arch_cpu.h for the x86 boot platform to group these things
in a single place, and adjust the BIOS and EFI code to call into that.
Note that the BIOS and EFI code is still a little platform specific,
ideally there should be a boot_arch_cpu_init() function for each
architecture as already done for openfirmware and u-boot.
Also remove some irrelevant comments from copypasted files for other
architectures, as that was filling my git grep with useless noise.
Change-Id: I16d815f0bf015cec0b4e03cc14f3cc447c7164c5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1985
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Get enough of the mmu working to be able to allocate memory.
Unlike on PowerPC, we get both address and size as 64bit values. So
adjust of_region to allow this.
Also unlike the PPC port, we do not drive the hardware directly, instead we
rely on the openboot primitives to manage the translation table. This
allows staying independant of the hardware, which is a good idea at
least for the bootloader (we can do actual hardware things in the
kernel)
Change-Id: Ifa57619d3a09b8f707e1f8640d8b4f71bb717e2a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1482
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Gets call-method working for sparc, and fix more places where we
accidentally truncate 64bit values or sign-extend 32 bit ones.
Change-Id: Ic79c55ffa8d2b475858def1639004412f17dd0c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1986
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Drop gnu-efi
Change-Id: Ib601fc8ced49b18281b6b98cf861a5aef1b9c065
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2026
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Move x86 hpet behind timer interface.
* Add a few if x86,x86_64 macros to start.cpp.
Change-Id: I583ec1b064785182e6d48dfbcd91b1bb2ead4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1929
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I88afad6d071e8b577c23da9c60392c60b3726514
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1895
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Non-KDEBUG kernels and kernel add-ons use atomic operations to acquire
and release the locks inline, so non-KDEBUG kernels/addons are only
compatible with other non-KDEBUG kernels/addons.
Following this change, though, KDEBUG kernels/addons should be able
to run under non-KDEBUG kernels/addons, too, since they always call
into the actual kernel functions and do not inline anything of
consequence.
This makes ARM64 target compile more files. This patch is one of
series of patches to support new architecture, as fixes in many
places are required just to compile the code.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia060612733cd3a0fcb781fec449da164ed635b8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1807
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This adds one (private) VFS function, and checks in all usages of
the vnode->cache as a VMVnodeCache that it really is one. (Generic
usages, for the moment just the ReleaseRef() calls in vnode
destruction, are intentionally not touched.)
This will be used by ramfs to set the cache from its own,
so that map_file() calls on a ramfs can work.
The patched errata are only the AMD ones FreeBSD patches
(it seems there are no Intel errata that can be patched
this way, they are all in microcode updates ... or can't
be patched in the CPU at all.)
This also seems to be roughly the point in the boot that
FreeBSD patches these, too, despite how "critical" some
of them seem.
Change-Id: I9065f8d025332418a21c2cdf39afd7d29405edcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1740
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Sparcv9 runs Openboot in 64 bit mode, which means the cell size is
64bit. Use intptr_t where appropriate to make the open firmware calls
work.
Beware, some values are still 32bit, this matters for example for
of_getprop, if you get 32bits into a 64bit variables it will be in the
MSB of it (big endian only weakness...) and confuse things. See for
example in console.cpp, where the input and output handles are retrieved
as 32bit values. It seems wise to check the expected size when using
of_getprop in these cases, instead of just checking for errors.
Change-Id: Ie72ebc4afe7c6d7602a47478f0bfb6b8247004b8
Reviewed-on: https://review.haiku-os.org/c/1369
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Before this commit, *all* ConditionVariable operations (yes, all;
even Wait, Notify, etc.) went through a single spinlock, that also
protected the sConditionVariableHash. This obviously does not scale
so well with core count, to say the least!
With this commit, we add spinlocks to each Variable and Entry.
This makes locking somewhat more complicated (and nuanced; see
inline comment), but the trade-off seems completely worth it:
(compile HaikuDepot in VMware, 2 cores)
before
real 1m20.219s
user 1m5.619s
sys 0m40.724s
after
real 1m12.667s
user 0m57.684s
sys 0m37.251s
The more cores there are, the more of an optimization this will
likely prove to be. But 10%-across-the-board is not bad to say
the least.
Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a
Even on 64bit CPUs it's a 32bit register.
Change-Id: I9a4de6eec225de19a90d70fae1382b662e530629
Reviewed-on: https://review.haiku-os.org/c/1625
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
B_OS_NAME_LENGTH is 32, char* is 8 (on x64), and this structure
has quite a lot of pointers in it so it is not like we really
needed to save those 24 bytes. Hitting malloc() in here is not
so great, especially because we usually have B_DONT_LOCK_KERNEL_SPACE
turned on, so just inline and avoid it.
Change-Id: I5c94955324cfda08972895826b61748c3b69096a
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
If the buildbots were working, I would have been informed of this
about an hour after I committed it last night. But it seems they aren't.
Maybe kallisti5 will have some more incentive to work on that?
Cleans up some lock/get/unlock sequences, and makes it possible
for external consumers to get team structs (which will be necessary
for permissions checks.)
* Now matches the rest of the architectures.
Change-Id: I6699e0c8f729923770f136f2c9599185a685336a
Reviewed-on: https://review.haiku-os.org/c/1527
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
Copied from PPC with the hooks for Apple hardware removed.
To be completed with the actual PCI bus implementation for Sun machines.
This is where we start doing machine specific stuff, apparently.
Change-Id: I06af4de9621e9d40593d153642478d928083e49a
Reviewed-on: https://review.haiku-os.org/c/1364
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
