better handling of very large memory maps
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- rust
- Bereich
- operating-systems, performance
Rechercherichtung
Beginne mit dem referenzierten Code in src/main.rs und src/binary/level_4_entries.rs und verfolge dann die Identity-Mapping-Logik des Bootloaders für BIOS-Speicherzuordnungsbereiche. Vergleiche die bereits geprüften Verbesserungen mit den zwei verbleibenden Vorschlägen: Lücken zu vermeiden und den unbrauchbaren reservierten Bereich an hohen Adressen auszuschließen. Erledigt bedeutet, eine sichere Mapping-Strategie auszuwählen und zu implementieren, ohne Abstürze oder unnötigen Aufwand während des Bootens.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Currently, the bootloader has some issues handling BIOS memory maps that contain very high addresses, such as around the 1TB mark, and/or very large regions (in excess of 500 GB). Depending on the bootloader version and configuration, memory maps with high addresses or large regions may result in crashes or degrade boot performance significantly.
In particular, the following issues have been observed:
- v0.9.x of
bootloadercontains an assertion that may be triggered when the memory map contains an address too big for a single PML4 entry if themap_physical_memoryfeature flag is enabled: https://github.com/rust-osdev/bootloader/blob/42da77b47558478c5a948d27cac80767b484eacc/src/main.rs#L289-L291 (see also phil-opp/blog_os#1138) - v0.10.x of
bootloaderdoesn't contain that assertion, but does have offset selection code that assumes no region will require multiple PML4 entries: https://github.com/rust-osdev/bootloader/blob/ac46d0455b41c11e5d316348d068df1c495ce0af/src/binary/level_4_entries.rs#L172-L174 - v0.10.x of
bootloaderexhibits very long boot times when a memory map contains a reserved region at a ~1TB offset. This is because the bootloader will identity map all pages up to the highest reserved address in the memory map using 4K pages, and does this twice (once for the bootloader itself, and a second time when setting up physical memory mappings for the kernel). This results in a very slow boot process.
These issues are relevant because AMD systems with an IOMMU have a reserved hole close to the 1TB mark. In recent QEMU versions (>= v7.1.0), QEMU will report this region as reserved in its e380 BIOS memory map, resulting in assertion failures or boot performance degradation. I would assume this would cause issues when booting on real AMD hardware, as well.
Some changes that would improve how bootloader handles high addresses in the memory map (many of which were suggested by @phil-opp on Gitter):
- Change the automatic offset selection to support regions that need multiple entries in the level 4 page table (v0.9.x, v0.10.x, and probably v0.11.x)
- Don't identity map reserved regions at all when performing the initial identity mapping for the bootloader itself (v0.10.x and probably v0.11.x)
- The framebuffer would still need to be identity mapped so that the bootloader can write to it.
- Use 2MB rather than 4KB pages when identity mapping the kernel address space, which would improve performance (v0.10.x and v0.11.x)
- Consider not identity mapping holes in the memory map at all, only the reserved regions that would need to be mapped for the kernel. This way, we wouldn't map every page between the second-highest reserved region and the 1TB hole on AMD systems.
- Consider not identity mapping that specific reserved region, at all. It's an unusable hole, not a MMIO region or BIOS structure that the kernel would actually want to access...
- Vorherrschende Sprache
- Rust
- Sterne
- 1.7k
- Forks
- 240
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus rust-osdev/bootloader
-
help wanted
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 67/100
rust-osdev/bootloader#581 · 2 Kommentare ·
-
No boot on real hardwareOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
rust-osdev/bootloader#573 · 5 Kommentare ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100
rust-osdev/bootloader#555 · 2 Kommentare ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
rust-osdev/bootloader#534 ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 38/100
rust-osdev/bootloader#525 ·
Alle Issues in rust-osdev/bootloader
Ähnliche Issues
-
backend::vllm diffusion multimodal
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
lambdaclass/ethrex#7329 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
shadowsocks/shadowsocks-rust#2186 · 1 Kommentar ·
-
C-bug S-awaiting-triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 92/100
juspay/hyperswitch#14479 ·
Maintainer antworten meist innerhalb von 1 Tag