On 13.10.2023 10:56, Roger Pau Monne wrote:
> The mapping of memory regions below the 1MB mark was all done by the PVH dom0
> builder code, causing the region to be avoided by the arch specific IOMMU
> hardware domain initialization code. That lead to the IOMMU being enabled
> without reserved regions in the low 1MB identity mapped in the p2m for PVH
> hardware domains. Firmware which happens to be missing RMRR/IVMD ranges
> describing E820 reserved regions in the low 1MB would transiently trigger
> IOMMU
> faults until the p2m is populated by the PVH dom0 builder:
>
> AMD-Vi: IO_PAGE_FAULT: 0000:00:13.1 d0 addr 00000000000eb380 flags 0x20 RW
> AMD-Vi: IO_PAGE_FAULT: 0000:00:13.1 d0 addr 00000000000eb340 flags 0
> AMD-Vi: IO_PAGE_FAULT: 0000:00:13.2 d0 addr 00000000000ea1c0 flags 0
> AMD-Vi: IO_PAGE_FAULT: 0000:00:14.5 d0 addr 00000000000eb480 flags 0x20 RW
> AMD-Vi: IO_PAGE_FAULT: 0000:00:12.0 d0 addr 00000000000eb080 flags 0x20 RW
> AMD-Vi: IO_PAGE_FAULT: 0000:00:14.5 d0 addr 00000000000eb400 flags 0
> AMD-Vi: IO_PAGE_FAULT: 0000:00:12.0 d0 addr 00000000000eb040 flags 0
>
> Those errors have been observed on the osstest pinot{0,1} boxes (AMD Fam15h
> Opteron(tm) Processor 3350 HE).
>
> Mostly remove the special handling of the low 1MB done by the PVH dom0
> builder,
> leaving just the data copy between RAM regions. Otherwise rely on the IOMMU
> arch init code to create any identity mappings for reserved regions in that
> range (like it already does for reserved regions elsewhere).
>
> Note there's a small difference in behavior, as holes in the low 1MB will no
> longer be identity mapped to the p2m.
I certainly like the simplification, but I'm concerned by this: The BDA
is not normally reserved, yet may want accessing by Dom0 (to see the real
machine contents). We do access that first page of memory ourselves, so
I expect OSes may do so as well (even if the specific aspect I'm thinking
of - the warm/cold reboot field - is under Xen's control).
Jan
