All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	linux-pci@vger.kernel.org, bhelgaas@google.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] PCI: Expose resource resizing through sysfs
Date: Wed, 17 Aug 2022 12:10:44 +0200	[thread overview]
Message-ID: <a15fe381-1f41-2c92-2ef1-0b4eb30a5142@amd.com> (raw)
In-Reply-To: <166067824399.1885802.12557332818208187324.stgit@omen>

Am 16.08.22 um 21:39 schrieb Alex Williamson:
> We have a couple graphics drivers making use of PCIe Resizable BARs
> now, but I've been trying to figure out how we can make use of such
> features for devices assigned to a VM.  This is a proposal for a
> rather basic interface in sysfs such that we have the ability to
> pre-enable larger BARs before we bind devices to vfio-pci and
> attach them to a VM.

Ah, yes please.

I was considering doing this myself just for testing while adding the 
rebar support for the GFX drivers, but then just implementing it on the 
GFX side was simpler.

I would just add a warning that resizing BARs can easily crash the 
system even when no driver directly claimed the resource or PCIe device.

It literally took me weeks to figure out that I need to kick out the EFI 
framebuffer driver before trying to resize the BAR or otherwise I just 
get a hung system.

> Along the way I found a double-free in the error path of creating
> resource attributes, that can certainly be pulled separately (1/).
>
> I'm using an RTX6000 for testing, which unexpectedly only supports
> REBAR with smaller than default sizes, which led me to question
> why we have such heavy requirements for shrinking resources (2/).

Oh, that's easy. You got tons of ARM boards with less than 512MiB of 
address space per root PCIe complex.

If you want to get a GPU working on those you need to decrease the BAR 
size or otherwise you won't be able to fit 256MiB VRAM BAR + register 
BAR into the same hole for the PCIe root complex.

An alternative explanation is that at least AMD produced some boards 
with a messed up resize configuration word. But on those you only got 
256MiB, 512MiB and 1GiB potential BAR sizes IIRC.

Anyway, with an appropriate warning added to the sysfs documentation the 
patch #2 and #3 are Acked-by: Christian König <christian.koenig@amd.com>

Regards,
Christian.

>
> The final patch proposes the sysfs interface and I'll leave the
> discussion there for whether this is a good approach.  Thanks,
>
> Alex
> ---
>
> Alex Williamson (3):
>        PCI: Fix double-free in resource attribute error path
>        PCI: Skip reassigning bridge resources if reducing BAR size
>        PCI: Expose PCIe Resizable BAR support via sysfs
>
>
>   Documentation/ABI/testing/sysfs-bus-pci |  27 +++++
>   drivers/pci/pci-sysfs.c                 | 126 +++++++++++++++++++++++-
>   drivers/pci/setup-res.c                 |   2 +-
>   include/linux/pci.h                     |   1 +
>   4 files changed, 154 insertions(+), 2 deletions(-)
>


  parent reply	other threads:[~2022-08-17 10:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 19:39 [PATCH 0/3] PCI: Expose resource resizing through sysfs Alex Williamson
2022-08-16 19:40 ` [PATCH 1/3] PCI: Fix double-free in resource attribute error path Alex Williamson
2022-08-16 19:40 ` [RFC PATCH 2/3] PCI: Skip reassigning bridge resources if reducing BAR size Alex Williamson
2022-08-16 19:41 ` [RFC PATCH 3/3] PCI: Expose PCIe Resizable BAR support via sysfs Alex Williamson
2022-08-17 10:10 ` Christian König [this message]
2022-08-17 14:02   ` [PATCH 0/3] PCI: Expose resource resizing through sysfs Alex Williamson
2022-08-18 11:16     ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a15fe381-1f41-2c92-2ef1-0b4eb30a5142@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.