linux-kernel - Re: [PATCH 0/3] PCI: Expose resource resizing through sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a15fe381-1f41-2c92-2ef1-0b4eb30a5142@amd.com>
Date:   Wed, 17 Aug 2022 12:10:44 +0200
From:   Christian König <christian.koenig@....com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        linux-pci@...r.kernel.org, bhelgaas@...gle.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] PCI: Expose resource resizing through sysfs

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@....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(-)
>