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
