Message-ID: <468ebc86-25aa-a22f-a45c-6ec15faa5b09@linux.intel.com>
Date: Fri, 24 Oct 2025 13:39:15 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Bjorn Helgaas <helgaas@...nel.org>
cc: Lucas De Marchi <lucas.demarchi@...el.com>, linux-pci@...r.kernel.org, 
    Bjorn Helgaas <bhelgaas@...gle.com>, 
    Krzysztof Wilczyński <kw@...ux.com>, 
    Christian König <christian.koenig@....com>, 
    Michał Winiarski <michal.winiarski@...el.com>, 
    Alex Deucher <alexander.deucher@....com>, amd-gfx@...ts.freedesktop.org, 
    David Airlie <airlied@...il.com>, dri-devel@...ts.freedesktop.org, 
    intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org, 
    Jani Nikula <jani.nikula@...ux.intel.com>, 
    Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, 
    Rodrigo Vivi <rodrigo.vivi@...el.com>, Simona Vetter <simona@...ll.ch>, 
    Tvrtko Ursulin <tursulin@...ulin.net>, 
    "Michael J . Ruhl" <mjruhl@...ana.ai>, 
    Andi Shyti <andi.shyti@...ux.intel.com>, 
    LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 00/11] PCI: Resizable BAR improvements

On Thu, 23 Oct 2025, Bjorn Helgaas wrote:

> On Thu, Oct 23, 2025 at 05:02:42PM -0500, Lucas De Marchi wrote:
> > On Thu, Oct 23, 2025 at 04:29:43PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Oct 22, 2025 at 04:33:20PM +0300, Ilpo Järvinen wrote:
> > > > pci.c has been used as catch everything that doesn't fits elsewhere
> > > > within PCI core and thus resizable BAR code has been placed there as
> > > > well. Move Resizable BAR related code to a newly introduced rebar.c to
> > > > reduce size of pci.c. After move, there are no pci_rebar_*() calls from
> > > > pci.c indicating this is indeed well-defined subset of PCI core.
> > > > 
> > > > Endpoint drivers perform Resizable BAR related operations which could
> > > > well be performed by PCI core to simplify driver-side code. This
> > > > series adds a few new API functions to that effect and converts the
> > > > drivers to use the new APIs (in separate patches).
> > > > 
> > > > While at it, also convert BAR sizes bitmask to u64 as PCIe spec already
> > > > specifies more sizes than what will fit u32 to make the API typing more
> > > > future-proof. The extra sizes beyond 128TB are not added at this point.
> > > > 
> > > > Some parts of this are to be used by the resizable BAR changes into the
> > > > resource fitting/assingment logic but these seem to stand on their own
> > > > so sending these out now to reduce the size of the other patch series.
> > > > 
> > > > v3:
> > > > - Rebased to solve minor conflicts
> > > > 
> > > > v2: https://lore.kernel.org/linux-pci/20250915091358.9203-1-ilpo.jarvinen@linux.intel.com/
> > > > - Kerneldoc:
> > > >   - Improve formatting of errno returns
> > > >   - Open "ctrl" -> "control"
> > > >   - Removed mislead "bit" words (when referring to BAR size)
> > > >   - Rewrote pci_rebar_get_possible_sizes() kernel doc to not claim the
> > > >     returned bitmask is defined in PCIe spec as the capability bits now
> > > >     span across two registers in the spec and are not continuous (we
> > > >     don't support the second block of bits yet, but this API is expected
> > > >     to return the bits without the hole so it will not be matching with
> > > >     the spec layout).
> > > > - Dropped superfluous zero check from pci_rebar_size_supported()
> > > > - Small improvement to changelog of patch 7
> > > > 
> > > > Ilpo Järvinen (11):
> > > >   PCI: Move Resizable BAR code into rebar.c
> > > >   PCI: Cleanup pci_rebar_bytes_to_size() and move into rebar.c
> > > >   PCI: Move pci_rebar_size_to_bytes() and export it
> > > >   PCI: Improve Resizable BAR functions kernel doc
> > > >   PCI: Add pci_rebar_size_supported() helper
> > > >   drm/i915/gt: Use pci_rebar_size_supported()
> > > >   drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()
> > > >   PCI: Add pci_rebar_get_max_size()
> > > >   drm/xe/vram: Use pci_rebar_get_max_size()
> > > >   drm/amdgpu: Use pci_rebar_get_max_size()
> > > >   PCI: Convert BAR sizes bitmasks to u64
> > > > 
> > > >  Documentation/driver-api/pci/pci.rst        |   3 +
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   8 +-
> > > >  drivers/gpu/drm/i915/gt/intel_region_lmem.c |  10 +-
> > > >  drivers/gpu/drm/xe/xe_vram.c                |  32 +-
> > > >  drivers/pci/Makefile                        |   2 +-
> > > >  drivers/pci/iov.c                           |   9 +-
> > > >  drivers/pci/pci-sysfs.c                     |   2 +-
> > > >  drivers/pci/pci.c                           | 145 ---------
> > > >  drivers/pci/pci.h                           |   5 +-
> > > >  drivers/pci/rebar.c                         | 314 ++++++++++++++++++++
> > > >  drivers/pci/setup-res.c                     |  78 -----
> > > >  include/linux/pci.h                         |  15 +-
> > > >  12 files changed, 350 insertions(+), 273 deletions(-)
> > > >  create mode 100644 drivers/pci/rebar.c
> > > 
> > > Applied to pci/rebar for v6.18, thanks, Ilpo!
> > 
> > is this for v6.18 or it's a typo and it's going to v6.19?
> 
> Oops, sorry, I meant v6.19!  I still have v6.18 regressions top of
> mind :)
> 
> > > If we have follow-on resource assignment changes that depend on these,
> > > maybe I'll rename the branch to be more generic before applying them.

Okay.

The bigger challenge, though, will be that it now seems I need to bite the 
bullet and rework the BAR resizing functions to fix v6.18-rc & v6.15 
regressions which will touch pci_resize_resource() or more to be more 
precise, add pci_release_and_resize_resource() interface. I've been 
postponing this as it seems quite intrusive and the upcoming resource 
fitting improvements should make driver initiated BAR resize pretty 
unnecessary anyway. It seems the shortcut didn't work. :-(

It will certainly conflict with the rebar.c move in this series. (I 
hopefully have the rework ready next week).

And sure, I've resource assignment changes piling up as well here, just 
have been busy with handling all the regression so I've not gotten to 
submit some of those. Most of them shouldn't conflict with rebar.c code 
anyway (probably only adding a few new helpers for the max rebar changes 
will but with the current state of affairs with all these regressions on 
my plate, the max rebar changes themselves seems already tracking 
next-next instead of 6.19).

> > > Also applied the drivers/gpu changes based on the acks.  I see the CI
> > > merge failures since this series is based on v6.18-rc1; I assume the
> > > CI applies to current linux-next or similar.  I'll check the conflicts
> > 
> > it tries on drm-tip that contains drm-xe-next going to v6.19. We have
> > some changes there that conflict, but shouldn't be hard.
>
> > We also need https://lore.kernel.org/linux-pci/20250918-xe-pci-rebar-2-v1-1-6c094702a074@intel.com/
> > to actually fix the rebar in some cases. Could you take a look?
> 
> Will do.  Remind me again if I forget!
> 
> Bjorn
> 

-- 
 i.

Powered by blists - more mailing lists