问题标签 [mmu]

让我们考虑该函数进行的以下系统调用

size_t read(int fildes, void *buf, size_t nbytes);从 unistd.h.

据我了解，操作系统将验证进行系统调用的进程是否被允许访问提供的放置读取数据的地址，即void *buf. 但为什么会这样呢？该地址是否提供了物理地址，因为它需要进行此检查？如果是，在进行系统调用之前，MMU 是否将地址转换为物理地址？一个进程如何提供一个它不允许访问的地址？我看不到如何将进程地址空间中的虚拟地址转换为不允许访问的物理地址。

1) 假设一个单级页表3
) 发生 TLB 未命中
3) 所需的页表在主存储器中可以执行吗？我想这不会是昂贵的硬件 4）MMU 获取物理页号（我想 MMU 必须以高 n 位作为虚拟页号和低 m 位作为物理页框号的格式保存它。请更正和解释我是否错了）问题：我想必须有一个键值映射，其中虚拟页面编号作为键，物理框架编号。作为价值。MMU 如何在页表中搜索键。如果它像线性搜索一样/w，那将是非常昂贵的。





5）使用硬件，它将偏移位附加到页帧号。

最后读取物理地址。

所以这个问题困扰着我很多，MMU如何在页表中搜索给定的键（虚拟页面条目）？

上下文（可能不需要）：

作为一项学习练习，我正在尝试为 Raspberry Pi 实现一个迷你“操作系统”。

我目前正在实现一个非常愚蠢的内存管理系统。我已经启用了 MMU，并且正在获取可用的 kmalloc。

它已经可以从预先存在的小内核堆中分配内存块，映射在代码和数据段之后。我试图通过映射更多页面来让它根据需要增长。它还必须能够产生物理上连续的块。

该代码托管在Github上，有一个专门用于调试代码的分支。请注意，这不是一个组织良好、注释良好或非常聪明的代码的示例。:)

实际问题：

在尝试调试数据中止时，我发现了一些非常奇怪的东西。

这是我的 kmalloc 中的一段代码：

我跑了三遍。结果如下：

第一次和第三次迭代看起来很正常（虽然 next_free 的值应该是 0，但数据中止是因为它有 0xffffffff）。但是我的代码在第二个期间在做什么？O_o 什么样的黑魔法可以让我的 printf 在连续读取四次时为 chunk->next_free 输出两个不同的值？o_o

数据对齐良好，页面可缓存且不可缓冲（使它们不可缓存无济于事），无论编译器优化是打开还是关闭，我都会得到相同的结果。我尝试在那里设置数据内存屏障，但实际上它什么也没做。我还检查了生产的组件，它看起来没问题。

我认为这可能是由损坏的 TLB 引起的。我在每个新页面映射后发出“使统一单一条目无效”(mcr p15, 0, %[addr], c8, c7, 1)。够了吗？

我尝试使用 qemu 进行调试，但在设置已用物理页面的位图时，它会提前中止数据，尽管这部分在 Pi 上运行良好。

我只是在寻找可能导致这种行为的线索。如果您需要更多上下文，请询问，尽管我的代码目前正在迅速变化并且由于大量 printf 而变得混乱。

ETA：前两个 printf 使用 -O0 的反汇编：

所以它把chunkr3 的地址放进去，然后执行 aldr来获取next_free。它在第二个prinf之前再次执行此操作。只有一个内核，DMA 没有运行，所以在调用之间没有改变内存中的值。

使用 -O2：

所以它仍然用ldr. 这就是为什么我在两个优化级别都得到相同的结果。

新编辑：我添加了更多 printfs，似乎奇点发生在这一点上：

在这行之后，chunk->next_free 变成了海森堡的猫。之前，它读为 0。

结构定义如下：

chunk并且next不要重叠。

如果我将“奇点线”移到 下方next->next_free = chunk->next_free，它会停止在两个值之间交替，但这仍然很奇怪： chunk->next_free 之前为 0 *prev_list = next，之后为 0xffffffff 。但是 next->next_free 仍然设置为 0。

我希望在 ARMv7 架构的引导程序（裸机）期间禁用 MMU。阅读 ARM ARM 我偶然发现了这一点。

“当 MMU 被禁用时，如果满足以下条件之一，则可以获取指令：

• 该指令与程序的简单顺序执行所需的指令位于相同的 4KB 内存块（与 4KB 对齐）中，或者位于紧跟该块的 4KB 内存块中。

• 该指令位于相同的 4KB 内存块中（与 4KB 对齐），之前在禁用 MMU 的情况下简单顺序执行程序需要一条指令，或者位于紧跟该块的 4KB 块中。”

任何人都可以解密并向我解释我如何确保指令在彼此相邻的 4KB/8KB 范围内？（这就是我理解这些陈述的方式..）

MMU的页表走逻辑是固定的吗？或者它是由内核配置的？

我虽然 MMU 的逻辑总是固定的，但似乎每个操作系统的页表结构都不同......或者当我添加更多物理存储卡时......

一些建议会很好提前谢谢你。

众所周知，在 32 位系统中，虚拟地址到物理地址的转换分为 3 个级别：

• PD(10 bit)：Page-Directory - 其中每个条目 (PDE) 对应于所需的 Page-Table 并定义了 4 MB 范围的转换（为了指示 PT，最高 20 位取自 PDE，并且剩下的 12 个用 0 填充）
• PT(10 bit)：Page-Table - 其中每个条目（PTE）对应于虚拟地址空间中的每个页面（4KB）（用于指示Page，最高20位取自PTE，其余12位为填充为 0)
• 偏移量（12 位） - 此页面内的偏移量

PDE 和 PTE 的前 12 位，不用于寻址（用零填充）具有以下属性：

但是它在 64 位系统x86_64上看起来如何：有多少层，它叫什么，与 32 位有什么不同以及使用了哪些属性？

我是 2 核的 ARM Cortex A9 CPU。但我只使用 1 个核心，而另一个只是处于繁忙循环中。我使用部分（每个条目 1MB）设置 MMU 表，如下所示：

这很简单。我只想拥有一个 256MB 内存的镜像，用于不可缓存的访问。但是，当我多次写入 0x95000000-0xa4ffffff 的不可缓存内存部分时。我发现在我明确给出缓存刷新之前实际上并未写入写入。

我做错了什么还是这种映射无效？如果是这样的话，我不明白 Linux 的 ioremap 将如何在 ARM 上运行。如果有人能给我一些解释，那就太好了。非常感谢。

在 ARMv7 VMSA MMU 中，存在 ttbr0 和 ttbr1 指向的两组转换表。ttbr0 或 ttbr1 指向的表将用于转换的虚拟地址范围由“N”字段 TTBCR 寄存器设置。

现在，如果我将此 TTBCR.N 设置为 7，则 ttbr0 处的转换表覆盖的地址范围为 0x00000000 - 0x2000000

所以 0x2000000 之后的第一个地址（即 0x2000004？）将使用 ttbr1 处的转换表进行转换。根据 ARMv7 VMSA 中的短描述符格式，转换表可以具有节 (1MB) 区域和超节 (16MB) 映射区域。

我的问题是如果我在地址位置放置一个超级部分会发生什么，比如 0x1600000。

根据理论，那么 0x1600000 到 0x2600000 范围内的地址将映射到物理地址 0x1600000。（但是，这不起作用，因为转换表本身在 0x2000000 处发生变化？）

那么在这种情况下会发生什么？在这种情况下，ttbr1 的第一个条目应该放什么？

我在我的板上使用 Cortex A8 CPU，并试图将具有地址空间的外部 SDRAM 映射0x7000_0000到0x7FFF_FFFF使用 16M 超部分。大小为 256 字的 MMU 描述符表（表中的每个条目是0x7005_1C0E, 0x7105_1C0E,.... 0x7F05_1C0E）被放置在片上 RAM 中0xF801_8000。由于正在使用超节，每个描述符在表中重复 16 次 - 因此表的大小为
256。TTBCR.N 为
0。TTBR0 包含相同的地址，0xF801_8000
当我通过写入协处理器启用 MMU 时，我获得预取中止。
有人可以帮我弄清楚我错过了什么吗？
谢谢

根据一些教程，我们将在 bootlaoder 开始时禁用 MMU 和 I/D-Caches。如果我理解正确，它旨在直接在程序中使用物理地址，所以如果我错了，请纠正我。谢谢！

其次，我们这样做是为了禁用 MMU 和缓存：

mrc P15, 0, R0, C1, C0, 0

bic R0, R0, #0x00002300 @ 清除位 13, 9:8

bic R0, R0, #0x00000087 @ 清除位 7, 2:0

orr R0, R0, #0x00000002 @ 设置位 2 (A) 对齐

orr R0, R0, #0x00001000 @ 设置位 12 (I) I-Cache

mcr P15, 0, R0, C1, C0, 0

D-Cache、MMU 和数据地址对齐故障检查已被清除位 2:0 禁用，但为什么我们在下面的仪器中立即启用位 2？确保这种操作是有效的？

最后一个问题是为什么 D-cache 被禁用但 I-caches 能够？加快仪器进程？