On Wed, Jan 29, 2020 at 06:29:27PM +0300, Sergei Miroshnichenko wrote:
> BARs and bridge windows are only allowed to be assigned to their
> parent bus's bridge windows, going up to the root complex's resources.
> So additional limitations on BAR address are not needed, and the
> PCIBIOS_MIN_MEM can be ignored.
This is theoretically true, but I don't think we have reliable
information about the host bridge windows in all cases, so
PCIBIOS_MIN_MEM/_IO is something of an approximation.
> Besides, the value of PCIBIOS_MIN_MEM reported by the BIOS 1.3 on
> Supermicro H11SSL-i via e820__setup_pci_gap():
>
> [mem 0xebff1000-0xfe9fffff] available for PCI devices
>
> is only suitable for a single RC out of four:
>
> pci_bus 0000:00: root bus resource [mem 0xec000000-0xefffffff window]
> pci_bus 0000:20: root bus resource [mem 0xeb800000-0xebefffff window]
> pci_bus 0000:40: root bus resource [mem 0xeb200000-0xeb5fffff window]
> pci_bus 0000:60: root bus resource [mem 0xe8b00000-0xeaffffff window]
>
> , which makes the AMD EPYC 7251 unable to boot with this movable BARs
> patchset.
Something's wrong if this system booted before this patch set but not
after. We shouldn't be doing *anything* with the BARs until we need
to, i.e., until we hot-add a device where we have to move things to
find space for it.
(And we don't want a bisection hole where this system can't boot until
this patch is applied, but I assume that's obvious.)
> Signed-off-by: Sergei Miroshnichenko <s.miroshnichenko@xxxxxxxxx>
> ---
> drivers/pci/setup-res.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index a7d81816d1ea..4043aab021dd 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -246,12 +246,13 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
> int resno, resource_size_t size, resource_size_t align)
> {
> struct resource *res = dev->resource + resno;
> - resource_size_t min;
> + resource_size_t min = 0;
> int ret;
> resource_size_t start = (resource_size_t)-1;
> resource_size_t end = 0;
>
> - min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
> + if (!pci_can_move_bars)
> + min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
I don't understand the connection here. PCIBIOS_MIN_MEM and
PCIBIOS_MIN_IO are basically ways to say "we can't put PCI resources
below this address".
On ACPI systems, the devices in the ACPI namespace are supposed to
tell the OS what resources they use, and obviously the OS should not
assign those resources to anything else. If Linux handled all those
ACPI resources correctly and in the absence of firmware defects, we
shouldn't need PCIBIOS_MIN_MEM/_IO at all. But neither of those is
currently true.
It's true that we should be smarter about PCIBIOS_MIN_MEM/_IO, but I
don't think that has anything to do with whether we support *moving*
BARs. We have to avoid the address space that's already in use in
*all* cases.
> if (pci_can_move_bars && dev->subordinate && resno >= PCI_BRIDGE_RESOURCES) {
> struct pci_bus *child_bus = dev->subordinate;
> --
> 2.24.1
>
