* This is needed in order to support syscalls and other exceptions
that need to be able to inspect/modify userspace register contents.
Change-Id: I8a638c0c40dd44ed882adad0591ae3bf5493a6b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8329
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Using the page attribute table to set the memory type on a per page
mapping basis is the more modern and flexible approach to physical
memory type handling compared to using MTRRs.
Most of the needed infrastructure was already in place, as setting the
page table entry attributes was already done for uncachable and
write-back memory types. Using the PAT now also allows to set the last
remaining memory type of write-combining through the PTE flags. The PAT
is configured to have entry 4 mean write-combining and the PAT bit in
the PTE is set to point to that.
When PAT is supported and not disabled, MTRRs are completely ignored
and left as set up by the system firmware, where the basic uncachable
and RAM ranges are supposed to be set up. These configurations are then
overridden by the PTE flags as needed.
Change-Id: I0a74b3fc7d3ba9fa384251290ce41621b69d3a02
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8340
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We allow requesting an explicit memory type when calling
map_physical_memory but default to the uncached B_MTR_UC when not given.
When called without an explicitly requested memory type, allow
arch_vm_set_memory_type to modify and return an effective memory type.
When an overlapping range already exists, the effective memory type is
set to the one of the existing mapping. If there is an explicit memory
type request that conflicts with an existing range, or if multiple
overlaps with conflicting types would be produced, the mapping is
disallow (and a panic is triggered under KDEBUG).
This effectively detects and panics when conflicting aliases of physical
memory would be created. This is also useful on an MTRR based setup,
as such overlaps cannot be properly represented.
When using the page attribute table (PAT) to set the memory type on a
per page virtual memory mapping basis, this is needed to prevent
aliasing of the same physical memory with different types. As per the
specs, such aliasing is unsupported and may result in undefined
operations that lead to system failure.
The mechanism is extended to the general arch_vm_set_memory_type as such
aliasing prevention also seems to apply to other architectures (at least
on ARM, aliasing is also strongly discouraged).
Change-Id: I7aaf6ea8415e92e74cd1643b67793a6857619eea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8339
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 0caf23319cb4e9f9c8a2ecd30e133e98a1d2b989.
This change is not safe because changing MAIR may invalidate
early mappings. It's also not clear if it's needed, as e.g.
FreeBSD does not use Device GRE mappings.
Change-Id: I95a904ee928281d44989ce707ed1ac59985a308d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8268
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Milek7 Milek7 <me@milek7.pl>
* This is the closest thing ARM has the semantics of write-combining
MTR on x86.
Change-Id: I12a1582e0af871e2ab729262e90695ffe928c85b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8223
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These are architecture-specific routines, so they deserve proper
architecture-specific naming. The user memory access routines are
already under arch_cpu (arch_cpu_user_memcpy, etc.), and the methods
usually change a CPU flag, so it makes sense to put these there too.
RISC-V had get_ac but nothing else defined or used it, so it's removed.
No functional change intended.
Change-Id: Id4715214e32f73d4a93bc7ba8249411a0878d174
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8106
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: X512 X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
According to the ARMv7 Reference Manual, "Wait for Interrupt" is supported only through the WFI instruction on ARMv7.
The currently used ARMv6 equivalent may not work on ARMv7 and newer CPUs.
Fixes #18520
Change-Id: I69a136870654be33c0c789004e08bf610db3dd97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8044
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's not used for anything by the OS but userspace might want
to use it for its own purposes.
Change-Id: Icda4bcd6de9d68596555e81293c8bd075f80a2a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7511
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is no-op for 32 bit platforms because `int32` is defined as `long` there.
Change interrupt vector number from 64 bits to 32 bits for 64 bit platforms.
Change-Id: I52d1ad616cab16488804e9733c7afaf772a670ba
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7507
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Also increase MSI message data size to 32 bits according to PCIe spec.
Remove 0xff check for MSI interrupts because it is potentially valid
interrupt vector number. Reject 0xff only for legacy pin interrupts.
- MSI-X supports up to 2048 interrupts per device that do not fit to
`uint8`.
- Non-x86 systems may use separate interrupt vector ranges for
hard-wired interrupts and MSI interrupts so `uint8` is not enough to
represent all of them.
Change-Id: Iaf9ffb197ec23db0f97ffe3ea756d28d7bfc8705
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7433
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
after a0131eaae2884fdced27158c3d34732d1656aca9 mxcsr was possibly also incorrect.
fpu control and mxcsr will be restored with fxrstor/xrstor.
no need to clear pending exceptions on #MF
fix #18656 (and #18624 after reverting).
Change-Id: I7dd5e2e4610747c5b82abd6c67e302d264b4be92
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7104
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* also on x86 for simplicity.
* fixes #18624
* also makes x87 FPU data registers available for x87 floating instructions. EMMS is cheap.
see 25209d81f7
Change-Id: I5c1b399377102f3eb10bc6d7f7247afbaf6d8483
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7089
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Only the x86 and PPC implementations look like they would have worked,
while the builtin is available and will work across all architectures.
We already use it unconditionally in some parts of libroot.
Change-Id: I2dffb3b2c7cdd605092382b9d649151adb921bb4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6942
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
ASID allocation is not supported yet, so always use ASID 0 for user pages for now.
Change-Id: I021e77dae692c22984bc625dd0588362bece45b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6698
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* 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 <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
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 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Ia16e66a7bdac37019e6256405b9f10024909c69a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6215
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
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 <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
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 <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
