system/serenity
system/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity synced 2024-07-22 10:36:24 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity
serenity/Kernel/Memory/TypedMapping.h

69 lines
2.2 KiB
C
Raw Normal View History

Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
*/
#pragma once
Kernel/Memory: Introduce a method to allocate TypedMapping on the heap This will be used later on to allocate such structure on the heap when it is necessary to do so.
2022-09-23 11:47:16 +00:00
#include <AK/NonnullOwnPtr.h>
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
#include <AK/StringView.h>
Kernel/Memory: Introduce a method to allocate TypedMapping on the heap This will be used later on to allocate such structure on the heap when it is necessary to do so.
2022-09-23 11:47:16 +00:00
#include <AK/Try.h>
Kernel: Rename Kernel/VM/ to Kernel/Memory/ This directory isn't just about virtual memory, it's about all kinds of memory management.
2021-08-06 08:45:34 +00:00
#include <Kernel/Memory/MemoryManager.h>
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
Kernel: Move Kernel/Memory/ code into Kernel::Memory namespace
2021-08-06 11:49:36 +00:00
namespace Kernel::Memory {
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
template<typename T>
struct TypedMapping {
Everywhere: Run clang-format
2022-10-16 22:06:11 +00:00
T const* ptr() const { return reinterpret_cast<T const*>(region->vaddr().offset(offset).as_ptr()); }
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
T* ptr() { return reinterpret_cast<T*>(region->vaddr().offset(offset).as_ptr()); }
Kernel/Memory: Add TypedMapping base_address method This method will be used to ease usage with the structure when we need to do virtual pointer arithmetics.
2022-03-27 14:51:16 +00:00
VirtualAddress base_address() const { return region->vaddr().offset(offset); }
Everywhere: Run clang-format
2022-10-16 22:06:11 +00:00
T const* operator->() const { return ptr(); }
Kernel: Add non-const version of TypedMapping::operator->()
2020-05-23 13:57:19 +00:00
T* operator->() { return ptr(); }
Everywhere: Run clang-format
2022-10-16 22:06:11 +00:00
T const& operator*() const { return *ptr(); }
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
T& operator*() { return *ptr(); }
OwnPtr<Region> region;
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 08:50:04 +00:00
PhysicalAddress paddr;
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
size_t offset { 0 };
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 08:50:04 +00:00
size_t length { 0 };
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
};
Kernel/Memory: Introduce a method to allocate TypedMapping on the heap This will be used later on to allocate such structure on the heap when it is necessary to do so.
2022-09-23 11:47:16 +00:00
template<typename T>
static ErrorOr<NonnullOwnPtr<TypedMapping<T>>> adopt_new_nonnull_own_typed_mapping(PhysicalAddress paddr, size_t length, Region::Access access = Region::Access::Read)
{
auto mapping_length = TRY(page_round_up(paddr.offset_in_page() + length));
Kernel: Stop allocating physical pages for mapped MMIO regions As MMIO is placed at fixed physical addressed, and does not need to be backed by real RAM physical pages, there's no need to use PhysicalPage instances to track their pages. This results in slightly reduced allocations, but more importantly makes MMIO addresses which end up after the normal RAM ranges work, like 64-bit PCI BARs usually are.
2024-05-10 20:16:01 +00:00
auto region = TRY(MM.allocate_mmio_kernel_region(paddr.page_base(), mapping_length, {}, access));
Kernel/Memory: Introduce a method to allocate TypedMapping on the heap This will be used later on to allocate such structure on the heap when it is necessary to do so.
2022-09-23 11:47:16 +00:00
auto table = TRY(adopt_nonnull_own_or_enomem(new (nothrow) Memory::TypedMapping<T>()));
table->region = move(region);
table->offset = paddr.offset_in_page();
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 08:50:04 +00:00
table->paddr = paddr;
table->length = length;
Kernel/Memory: Introduce a method to allocate TypedMapping on the heap This will be used later on to allocate such structure on the heap when it is necessary to do so.
2022-09-23 11:47:16 +00:00
return table;
}
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
template<typename T>
Kernel: Make map_typed() & map_typed_writable() fallible using ErrorOr This mostly just moved the problem, as a lot of the callers are not capable of propagating the errors themselves, but it's a step in the right direction.
2022-01-13 16:20:22 +00:00
static ErrorOr<TypedMapping<T>> map_typed(PhysicalAddress paddr, size_t length, Region::Access access = Region::Access::Read)
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
{
TypedMapping<T> table;
Kernel: Make map_typed() & map_typed_writable() fallible using ErrorOr This mostly just moved the problem, as a lot of the callers are not capable of propagating the errors themselves, but it's a step in the right direction.
2022-01-13 16:20:22 +00:00
auto mapping_length = TRY(page_round_up(paddr.offset_in_page() + length));
Kernel: Stop allocating physical pages for mapped MMIO regions As MMIO is placed at fixed physical addressed, and does not need to be backed by real RAM physical pages, there's no need to use PhysicalPage instances to track their pages. This results in slightly reduced allocations, but more importantly makes MMIO addresses which end up after the normal RAM ranges work, like 64-bit PCI BARs usually are.
2024-05-10 20:16:01 +00:00
table.region = TRY(MM.allocate_mmio_kernel_region(paddr.page_base(), mapping_length, {}, access));
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
table.offset = paddr.offset_in_page();
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 08:50:04 +00:00
table.paddr = paddr;
table.length = length;
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
return table;
}
template<typename T>
Kernel: Make map_typed() & map_typed_writable() fallible using ErrorOr This mostly just moved the problem, as a lot of the callers are not capable of propagating the errors themselves, but it's a step in the right direction.
2022-01-13 16:20:22 +00:00
static ErrorOr<TypedMapping<T>> map_typed(PhysicalAddress paddr)
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
{
return map_typed<T>(paddr, sizeof(T));
}
template<typename T>
Kernel: Make map_typed() & map_typed_writable() fallible using ErrorOr This mostly just moved the problem, as a lot of the callers are not capable of propagating the errors themselves, but it's a step in the right direction.
2022-01-13 16:20:22 +00:00
static ErrorOr<TypedMapping<T>> map_typed_writable(PhysicalAddress paddr)
Kernel: Add typed_map<T>(PhysicalAddress) and use it in ACPI parsing There was a frequently occurring pattern of "map this physical address into kernel VM, then read from it, then unmap it again". This new typed_map() encapsulates that logic by giving you back a typed pointer to the kind of structure you're interested in accessing. It returns a TypedMapping<T> that can be used mostly like a pointer. When destroyed, the TypedMapping object will unmap the memory. :^)
2020-04-09 15:12:58 +00:00
{
return map_typed<T>(paddr, sizeof(T), Region::Access::Read | Region::Access::Write);
}
}
Reference in a new issue Copy permalink