Re: [RFC] xen/x86: allow overlaps with non-RAM regions

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.04.2025 03:01, Stefano Stabellini wrote:
> On one Sapphire AMD x86 board, I see this:
> 
> 
> (XEN) [0000003943ca6ff2]  [00000000f0000000, 00000000f7ffffff] (reserved)
> (XEN) [00000039460886d9]  [00000000fd000000, 00000000ffffffff] (reserved)
> [...]
> (XEN) [    4.612235] 0000:02:00.0: not mapping BAR [fea00, fea03] invalid 
> position

I, too, see something like this on an SPR system. That's a firmware issue,
which hence first of all should be dealt with at the firmware side.

> Linux boots fine on this platform but Linux as Dom0 on Xen does not.
> This is because the pci_check_bar->is_memory_hole check fails due to the
> MMIO region overlapping with the EFI reserved region.

And then what's the actual, observable problem? On my system I haven't
noticed anything going wrong yet, albeit the affected device is also left
without a driver.

Also aiui you strictly mean PVH Dom0 here?

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -797,6 +797,9 @@ bool is_memory_hole(mfn_t start, mfn_t end)
>          if ( !entry->size )
>              continue;
>  
> +        if ( entry->type > 1 )
> +            continue;

I'm sorry to ask, but what's a literal 1 here? I'm pretty convinced we
would want to still object to overlaps with unusable ranges, for example.
Yet by open-coding what E820_RAM expands to you completely hide what this
check is about. Yes, this is an RFC, but even there such context is
important.

Furthermore my general take here is: We shouldn't simply silence issues
arising from firmware doing odd things. My take here is still the same
as the position I took when I still was maintainer of the EFI code in
Xen: We shouldn't by default work around such issues, when doing so may
negatively affect systems not exposing such odd behavior.

Finally a Misra-related observation while looking at this: Isn't
is_memory_hole() unreachable code in a !HVM configuration?

Jan