* Introduce SWDBM flag similarly to the arm64 port
* Reuse TEX[2] for SWDBM flag which should be availble
to be used by the operating system if TEX remap
is enabled.
* Introduce SetAndClearPageTableEntryFlags for updating
accessed and modified flags atomically
* Startup sequence is handled similarly to accessed flag, i.e.
set Modified flag in initially mapped pages in bootloader and early map.
* Once the kernel initialization has progressed enough,
pages are mapped as read-only and modified flag handling is done
in the page fault handler.
Change-Id: I8f761e2c6325d1b91481abd569d5e8befded0761
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6518
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Condition variables are now a pretty common way the kernel blocks threads.
That means the "threads" command was getting difficult to navigate, since
at any given time, a lot of threads could be blocked on "cvar".
Now we try (carefully, because it could fault!) to fetch the first 4
characters of the "type" name and display then. This suffices to
distinguish the most common object block types in the list at a glance
(e.g. "cvar:port" for port reads, the most common.)
Change-Id: I94f4b59fd78b7ebdce913944551a5e98f0ca2e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6605
Reviewed-by: waddlesplash <[email protected]>
This allows to see the display in Screen preferences, and know its DPI
and physical size (as much as EDID data can be trusted). This
information could be used to compute the default font size, for example,
so it's important that all drivers provide it whenever possible.
Change-Id: Ic3d04e53cf5fcb24e22d35661d2b364a257947da
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6576
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Suppose the following scenario:
1. Thread A holds a mutex.
2. Thread B goes to acquire the mutex, winds up in kernel waiting.
3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)
4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.
5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.
6. Thread A, suspended back in step 3, resumes.
Now we encounter the problem. Under the previous code, the following
would occur.
7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!
8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!
The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.
Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.
That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.
Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.
Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.
Fixes#18436.
Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
We must do this to prevent lock order inversion: when busses are
initialized, they are started by the (locked) device manager, and
then acquire the explore lock. We must do the same in Explore itself,
for when called by the explore thread, we would otherwise first acquire
the explore lock, then (when publishing new nodes) acquire the device lock.
Should fix#18421 and #18393.
- Resize the `page_protections` array in `cut_area` and also shift
the bits if necessary.
- Set the correct protection array as well as the real page
protections for the second area produced by `cut_area`.
Change-Id: I62293480487e828970ebe5a3bc729cec2a14c687
- Add support for retrieving the `siginfo_t` structure of a signal
event from the Debugger API.
- Add code to `strace` to display this information every time a
signal event occurs, similar to the Linux `strace` tool.
Change-Id: If4e92bbae049ee0b52efaf9fc911d66511da62f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6393
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Introduce a new utility method, "generic_memcpy", which takes
generic_addr_t plus indications of whether these specify virtual or
physical addresses (and potentially user addresess) and calls the
appropriate memcpy variant depending.
All bus drivers adjusted to support this at once. We don't actually
take advantage of the physical addresses in any way (yet), as USB
controllers have some pretty specific requirements that would have
to be carefully validated to use these directly.
All bus drivers tested and confirmed to still be working.
Change-Id: I66326667e148091147bb2b3d0843a26fb7e5bda6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6479
Reviewed-by: waddlesplash <[email protected]>
This way it is more easily accessed from drivers outside the kernel,
which it soon will be, without having to add an explicit UseHeaders.
(The drivers that use it already all use the IOScheduler.)
No functional change.
Change-Id: Ibc2d2678e37d9d7ab73391cb17b72cca86f92132
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6477
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Before the PCI refactor, PCI initialization/enumeration occurred
immediately after the PCI module was loaded, and so by the time
we got to IOAPIC initialization, it was already complete.
After the refactor, PCI enumeration is deferred until slightly later,
and so we would try to initialize IO-APICs without knowing PCI
information. This would fail, as read_irq_routing_table needs to
have that available.
Hopefully fixes#18425, #18393, #18398.
Change-Id: I1e4b06367da26eeb10085a1c6322ed39885b632b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6476
Reviewed-by: X512 <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
- Stored the additional start time of each team, expressed by
milliseconds since boot.
- Added more fields to the `team_info` structure. These field
include those provided by the `get_extended_team_info` syscall as
well as the newly introduced `start_time`.
- Extended the `_kern_get_team_info` system call to receive an
additional `size_t` argument. If this size is smaller than or
equal to the size of the old `team_info` structure, the newly
added attributes will not be retrieved.
Change-Id: I22ee6b91ad2ee3b66a7f770036c79a718c5f115c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6390
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jessica Hamilton <[email protected]>
This new driver uses the "generic" TTY layer, unlike the old driver
which had its own implementation (which the generic module was derived
from, originally.)
The remaining bits of support for controlling TTYs is added to the kernel &
generic layer at the same time, which should allow for serial interfaces
to be controlling terminals now, as well.
Tested with bash, nano, vim; all seems to still be working as expected.
* Make some code common in Insert.
* Remove unneeded logic from InsertAfter and just call the base Insert.
InsertBefore does this, already.
* Synchronize Insert code and APIs in the fs_shell DoublyLinkedList.
Removing it outright would cause implicit conversions and then the other
variant being called, which would create invalid lists. So make it private
so that any attempts to use it will create errors at compile-time.
Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.
A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.
This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).
On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*
Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.
My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.
Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
we detect basically the cpu info before loading the microcode,
to be able to detect the vendor, and avoid any update on hypervisor.
I couldn't test because my cpu doesn't have any update available.
Change-Id: I6aea830158423b3ee13b640be8a788fc9041e23c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5859
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
tested on Zen2 (Ryzen 3 5300U)
This support was submitted in October for inclusion in Linux.
Haiku supports only two profiles. We could probably add some more, and let the driver says which it supports.
Change-Id: Id7754b445bc32a691d58a1e4af630351562abc22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5826
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This methods do not need DoublyLinkedList class state.
sGetLink field that actually implement GetPrevious/GetNext methods is already static.
Change-Id: Ie0b40f7f1b72d640d75403905b8944666874dc87
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5796
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
for legacy and new drivers.
This is an opcode for ioctl that can be used on almost any device entry found in /dev.
When used, ioctl will fill a buffer with the absolute path to the driver file that is
being used by the device.
This opcode was available in BeOS R5, though remained unimplemented in Haiku since
the introduction of the Device Manager almost two decades ago.
Original change by Jacob Secunda.
Change-Id: Ic49141b677b4158a63918459d4048450c825447c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5078
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
* This seems to be required when building the DriveEncryption kernel
driver with gcc 11.2 on x86-64, at least.
Change-Id: Ie1ae09435dd912021957e64d4b9a3e7b05913c33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5742
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
only scsi_disk checks the actual value, other drivers take the logical block size.
This change reports the physical block size from the disk rather than the block
size used by IDE/SATA/SCSI commands. On typical modern SATA disks, the SATA
commands will use 512 byte blocks, but the disk will actually read and write
4K blocks internally. This is only of importance for partition alignment for DriveSetup,
and is independant of file systems or partitioning systems. This could also influence
the recommended block size for some file systems.
Change-Id: Id0f2e22659e89fcef64c1f8d04f81cd68995e01f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5667
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* set PXN for all page tables below KERNEL_BASE
* also set PXN for physical page mapper
PXN, Privileged execute-never
When the PXN bit is 1, a Permission fault is generated if the processor
is executing at PL1 and attempts to execute an instruction fetched from
the corresponding memory region.
Change-Id: I3056cbed151004ac9edfbc81ebeada328aeb603c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5607
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Use the Privileged Only Thread ID Register aka TPIDRPRW to store
the current thread pointer.
The Privileged Only Thread ID Register is only accessible
in privileged modes, and is read/write.
see: ARMv7 Architecture Reference Manual,
section B3.12.46 CP15 c13 Software Thread ID registers
Change-Id: I5273bee8a80b78cdc547b2f6c96632d120eb3d55
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5608
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
David Karoly