linux-kernel - Re: [RFC] Resizable BARs vs bridges with BARs

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <fe0e40cb-b982-2aba-b622-8534c174ea39@amd.com>
Date:   Sat, 19 Nov 2022 12:02:55 +0100
From:   Christian König <christian.koenig@....com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RFC] Resizable BARs vs bridges with BARs

Hi Alex,

Am 19.11.22 um 00:09 schrieb Alex Williamson:
> Hi,
>
> I'm trying to get resizable BARs working in a configuration where my
> root bus resources provide plenty of aperture for the BAR:
>
> pci_bus 0000:5d: root bus resource [io  0x8000-0x9fff window]
> pci_bus 0000:5d: root bus resource [mem 0xb8800000-0xc5ffffff window]
> pci_bus 0000:5d: root bus resource [mem 0xb000000000-0xbfffffffff window] <<<
> pci_bus 0000:5d: root bus resource [bus 5d-7f]
>
> But resizing fails with -ENOSPC.  The topology looks like this:
>
>   +-[0000:5d]-+-00.0-[5e-61]----00.0-[5f-61]--+-01.0-[60]----00.0  Intel Corporation DG2 [Arc A380]
>                                               \-04.0-[61]----00.0  Intel Corporation Device 4f92
>
> The BIOS is not fluent in resizable BARs and only programs the root
> port with a small aperture:
>
> 5d:00.0 PCI bridge: Intel Corporation Sky Lake-E PCI Express Root Port A (rev 07) (prog-if 00 [Normal decode])
>          Bus: primary=5d, secondary=5e, subordinate=61, sec-latency=0
>          I/O behind bridge: 0000f000-00000fff [disabled]
>          Memory behind bridge: b9000000-ba0fffff [size=17M]
>          Prefetchable memory behind bridge: 000000bfe0000000-000000bff07fffff [size=264M]
>          Kernel driver in use: pcieport
>
> The trouble comes on the upstream PCIe switch port:
>
> 5e:00.0 PCI bridge: Intel Corporation Device 4fa1 (rev 01) (prog-if 00 [Normal decode])
>     >>>  Region 0: Memory at b010000000 (64-bit, prefetchable)
>          Bus: primary=5e, secondary=5f, subordinate=61, sec-latency=0
>          I/O behind bridge: 0000f000-00000fff [disabled]
>          Memory behind bridge: b9000000-ba0fffff [size=17M]
>          Prefetchable memory behind bridge: 000000bfe0000000-000000bfefffffff [size=256M]
>          Kernel driver in use: pcieport
>
> Note region 0 of this bridge, which is 64-bit, prefetchable and
> therefore conflicts with the same type for the resizable BAR on the GPU:
>
> 60:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A380] (rev 05) (prog-if 00 [VGA controller])
>          Region 0: Memory at b9000000 (64-bit, non-prefetchable) [disabled] [size=16M]
>          Region 2: Memory at bfe0000000 (64-bit, prefetchable) [disabled] [size=256M]
>          Expansion ROM at <ignored> [disabled]
>          Capabilities: [420 v1] Physical Resizable BAR
>                  BAR 2: current size: 256MB, supported: 256MB 512MB 1GB 2GB 4GB 8GB
>
> It's a shame that the hardware designers didn't mark the upstream port
> BAR as non-prefetchable to avoid it living in the same resource
> aperture as the resizable BAR on the downstream device.

This is expected. Bridges always have a 32bit non prefetchable and a 
64bit prefetchable BAR. This is part of the PCI(e) spec.

> In any case, it's my understanding that our bridge drivers don't generally make use
> of bridge BARs.  I think we can test whether a driver has done a
> pci_request_region() or equivalent by looking for the IORESOURCE_BUSY
> flag, but I also suspect this is potentially racy.

That sounds like we have a misunderstanding here how those bridges work. 
The upstream bridges should include all the resources of the downstream 
devices/bridges in their BARs.

> The patch below works for me, allowing the new resourceN_resize sysfs
> attribute to resize the root port window within the provided bus
> window.  Is this the right answer?  How can we make it feel less
> sketchy?  Thanks,

The correct approach is to remove all the drivers (EFI, vesafb etc...) 
which are using the PCI(e) devices under the bridge in question. Then 
release the resources and puzzle everything back together.

See amdgpu_device_resize_fb_bar() how to do this correctly.

Regards,
Christian.

>
> Alex
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index b4096598dbcb..8c332a08174d 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -2137,13 +2137,19 @@ int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
>   	next = bridge;
>   	do {
>   		bridge = next;
> -		for (i = PCI_BRIDGE_RESOURCES; i < PCI_BRIDGE_RESOURCE_END;
> +		for (i = PCI_STD_RESOURCES; i < PCI_BRIDGE_RESOURCE_END;
>   		     i++) {
>   			struct resource *res = &bridge->resource[i];
>   
>   			if ((res->flags ^ type) & PCI_RES_TYPE_MASK)
>   				continue;
>   
> +			if (i < PCI_STD_NUM_BARS) {
> +				if (!(res->flags & IORESOURCE_BUSY))
> +					pci_release_resource(bridge, i);
> +				continue;
> +			}
> +
>   			/* Ignore BARs which are still in use */
>   			if (res->child)
>   				continue;
>