Re: [PATCH for-4.21] vpci/msix: improve handling of bogus MSI-X capabilities

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/30/25 2:46 PM, Roger Pau Monné wrote:

> On Mon, Sep 29, 2025 at 05:59:00PM +0200, Oleksii Kurochko wrote:
> > On 9/29/25 10:41 AM, Roger Pau Monne wrote:
> > > I've had the luck to come across a PCI card that exposes a MSI-X capability
> > > where the BIR of the vector and PBA tables points at a BAR that has 0 size.
> > >
> > > This doesn't play nice with the code in vpci_make_msix_hole(), as it would
> > > still use the address of such empty BAR (0) and attempt to crave a hole in
> > > the p2m.  This leads to errors like the one below being reported by Xen:
> > >
> > > d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
> > >
> > > And the device left unable to enable memory decoding due to the failure
> > > reported by vpci_make_msix_hole().
> > >
> > > Introduce checking in init_msix() to ensure the BARs containing the MSI-X
> > > tables are usable.  This requires checking that the BIR points to a
> > > non-empty BAR, and the offset and size of the MSI-X tables can fit in the
> > > target BAR.
> > >
> > > This fixes booting PVH dom0 on Supermicro AS -2126HS-TN severs with AMD
> > > EPYC 9965 processors.  The broken device is:
> > >
> > > 22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
> > >
> > > There are multiple of those integrated controllers in the system, all
> > > broken in the same way.
> > >
> > > Signed-off-by: Roger Pau Monné<roger.pau@xxxxxxxxxx>
> > > ---
> > > Cc: Stewart Hildebrand<stewart.hildebrand@xxxxxxx>
> > > Cc: Jan Beulich<jbeulich@xxxxxxxx>
> > > Cc: Oleksii Kurochko<oleksii.kurochko@xxxxxxxxx>
> > >
> > > While not strictly a bugfix, I consider this a worthy improvement so that
> > > PVH dom0 has a chance to boot on hardware that exposes such broken MSI-X
> > > capabilities.
> > >         
> > Based on your commit description it looks like a bug as without it, for example,
> > SATA controller can't be used, right?
> >
> > >   Hence I think this change should be considered for inclusion
> > > into 4.21.  There a risk of regressing on hardware that was already working
> > > with PVH, but given enough testing that should be minimal.
> > >         
> > We have some PVH tests in Xen’s GitLab CI, but I assume that isn’t enough?
> >       
> It's a very specific controller, which we don't seem to have any
> examples of in the lab.  The model is in the commit message.  Without
> this fix the device doesn't work as expected when used in PVH dom0
> mode.
>     
Thanks for the explanation.

I think we should consider to have this in 4.21 as it is still a fix of bogus
behavior:
 Released-Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

~ Oleksii