[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0



On Thu, May 22, 2025 at 11:44:24AM -0400, Stewart Hildebrand wrote:
> On 5/22/25 10:59, Jan Beulich wrote:
> > On 22.05.2025 16:03, Roger Pau Monne wrote:
> >> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> >> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> >> --- a/xen/arch/x86/pci.c
> >> +++ b/xen/arch/x86/pci.c
> >> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, 
> >> unsigned int bdf,
> >>  
> >>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
> >>  {
> >> +    /*
> >> +     * Refuse to map BARs at position 0, those are not initialized.  This 
> >> might
> >> +     * be required by Linux, that can reposition BARs with memory decoding
> >> +     * enabled.  By returning false here bar->enabled will be set to 
> >> false, and
> >> +     * bar_write() will work as expected.
> >> +     */
> >> +    if ( mfn_eq(start, _mfn(0)) )
> >> +        return false;
> > 
> > Is this really x86-specific?
> 
> No, I think Arm would benefit from this check too. I'm in favor of
> moving the check to common.

I think on ARM pci_check_bar() is more strict, and doesn't really need
this check since it explicitly checks whether the BAR falls inside of
a bridge window.

So unless you have a bridge window at mfn 0 this won't make a
difference.  And if you have a bridge window at mfn 0 you really want
to be able to position BARs at address 0.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.