|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3] vpci/msix: check for BARs enabled in vpci_make_msix_hole
On 04.03.2026 17:54, Roger Pau Monné wrote:
> On Wed, Mar 04, 2026 at 10:39:56AM -0500, Stewart Hildebrand wrote:
>> On 3/4/26 10:23, Roger Pau Monné wrote:
>>> On Wed, Feb 25, 2026 at 09:57:38PM -0500, Stewart Hildebrand wrote:
>>>> A hotplugged PCI device may be added uninitialized. In particular,
>>>> memory decoding might be disabled and the BARs might be zeroed. In this
>>>> case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole()
>>>> unconditionally attempts to punch holes in p2m, leading to init_msix()
>>>> failing:
>>>>
>>>> (XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0
>>>> clobbers MSIX MMIO area
>>>> (XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it
>>>>
>>>> vpci_make_msix_hole() should only attempt to punch holes if the BARs
>>>> containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper
>>>> for checking if a BAR is enabled, and add a check for the situation
>>>> inside vpci_make_msix_hole().
>>>>
>>>> As a result of the newly introduced checks in vpci_make_msix_hole(),
>>>> move the call to vpci_make_msix_hole() within modify_decoding() to after
>>>> setting ->enabled.
>>>>
>>>> Fixes: ee2eb6849d50 ("vpci: Refactor REGISTER_VPCI_INIT")
>>>> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
>>>
>>> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>
>>> Thanks.
>>
>> Thanks!
>>
>> I would like to point out that this now needs a rebase:
>> The helper vmsix_table_bar_valid() should be moved to the new private.h.
>> I'd be happy to send v4, assuming I can retain your R-b.
>
> Sure, please keep the RB.
I was actually going to see about doing the rebasing when doing my next sweep
(pretty soon, i.e. after finishing going through email).
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |