|
[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 5/22/25 12:24, Roger Pau Monné wrote:
> 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.
True, but I was thinking more generally: if a BAR is not initialized,
don't map it. On Arm, it seems to be hit or miss whether BARs have been
initialized or not. I guess the difficulty lies in whether comparing to
zero is a reliable test to determine if the BAR is uninitialized.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |