On 12/02/2024 2:38 pm, Jan Beulich wrote: > On 07.02.2024 16:34, Roger Pau Monne wrote: >> Use the newly introduced generic unity map checker. >> >> Also drop the message recommending the usage of iommu_inclusive_mapping: the >> ranges would end up being mapped anyway even if some of the checks above >> failed, regardless of whether iommu_inclusive_mapping is set. Plus such >> option >> is not supported for PVH, and it's deprecated. >> >> Signed-off-by: Roger Pau Monné <[email protected]> > Reviewed-by: Jan Beulich <[email protected]>
XenRT says no. It's not clear exactly what's going on here, but the latest resync with staging (covering only today's pushed changes) suffered 4 failures to boot, on a mix of Intel hardware (SNB, SKL, SKX and CLX). All 4 triple-fault-like things where following a log message about an RMRR: (XEN) RMRR: [0x0e8 ,0x0e8] is not (entirely) in reserved memory not being in reserved memory. First of all - fix this printk() to print full addresses, not frame numbers. It's obnoxious to cross reference with the E820. In the example above, 0xe8000 is regular RAM in: (XEN) [0000000000000000, 000000000009d3ff] (usable) In another example, (XEN) RMRR: [0x4d800 ,0x4ffff] is not (entirely) in reserved memory is a hole between: (XEN) [000000004d3ff000, 000000004d3fffff] (usable) (XEN) [00000000e0000000, 00000000efffffff] (reserved) We should also explicitly render holes when printing the E820, because that's also unnecessarily hard to spot. It's very likely something in this series, but the link to Intel might just be chance of which hardware got selected, and I've got no clue why there's a reset with no further logging out of Xen... ~Andrew
