x86/xen: use UNUSABLE e820 regions for foreign mappings
Needs ReviewPublic
Actions

Authored by royger on Mar 6 2024, 9:39 AM.

Details

Reviewers

Summary

The current approach is to create foreign mappings in any unpopulated address
on the memory map. This however can cause issues, as late-loaded drivers could
then found their MMIO region has been stolen to be used as foreign mapping
scratch space (due to the Xen drivers having started first).

Workaround this on dom0 by using UNUSABLE e820 ranges as scratch space for
foreign mappings. The e820 memory map provided to dom0 is based on the native
one, but since PVH dom0 uses second stage translation, the UNUSABLE ranges on
the host memory map doesn't affect it, and we can also guarantee no device
MMIO uses those.

Additionally, any RAM in the e820 not available to dom0 because dom0
memory has been limited on the command line, or because those are in use by
Xen, are converted to UNUSABLE in the dom0 memory map.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

royger created this revision.Mar 6 2024, 9:39 AM

Herald added subscribers: ehem_freebsd_m5p.com, imp. · View Herald TranscriptMar 6 2024, 9:39 AM

royger requested review of this revision.Mar 6 2024, 9:39 AM

This is oddly similar to what Julien Grall did in 2015. For aarch64 the suggested range for the shared information page is available to the platform device. Perhaps the architecture should pass the struct resource * to xenpv?

In D44251#1009698, @ehem_freebsd_m5p.com wrote:

This is oddly similar to what Julien Grall did in 2015. For aarch64 the suggested range for the shared information page is available to the platform device. Perhaps the architecture should pass the struct resource * to xenpv?

If that works for Arm, I don't see why not. Just to be clear, you are suggesting that the only arch-specific bit is the initialization of mem_rman if I understand correctly?

I think so (suddenly worried about famous last words).