On Wed, Mar 22, 2017 at 12:39:57PM +0000, Ard Biesheuvel wrote:

[...]

quoted

quoted

Well, it turned out that this does not actually work: the BAR is not
reassigned, but the same range ends up being given to another device
in some cases.

Ok, that's because the PCI core just prevent assigning that resource
but it does not request it (ie insert it in the resource tree) which
is what you do when claiming it.

Yes, that seems to be what is happening.

quoted

I wonder how IORESOURCE_PCI_FIXED works on eg x86, I think it is time
to have a proper look into resources allocation code because there
are bits and pieces that are quite obscure to me.

I did a quick test with calling request_mem_region(), in which case we
end up with something like

10000000-3efeffff : PCI Bus 0000:00
  10000000-101d4bff : efifb:pci
  101d5000-101d5fff : 0000:00:01.0
  101d6000-101d6fff : 0000:00:02.0
  101d7000-101d7fff : 0000:00:04.0
    101d7000-101d7fff : ehci_hcd
  101d8000-101d8fff : 0000:00:05.0
  101e0000-101effff : 0000:00:05.0
  10200000-1023ffff : 0000:00:02.0

which works, because the region is no longer assigned to another BAR.

But I think claiming the resource via the PCI subsystem is probably
more appropriate, because then we get

Yes it is.

10000000-3efeffff : PCI Bus 0000:00
  10000000-10ffffff : 0000:00:05.0
    10000000-101d4fff : efifb
  11000000-1103ffff : 0000:00:02.0
  11040000-1104ffff : 0000:00:05.0
  11050000-11050fff : 0000:00:01.0
  11051000-11051fff : 0000:00:02.0
  11052000-11052fff : 0000:00:04.0
    11052000-11052fff : ehci_hcd
  11053000-11053fff : 0000:00:05.0

(Note that efifb does not use the entire BAR resource)

quoted

I think I would reverse the order in which you carry out the BAR
reservation anyway (first check if the device is enabled second request
the resource ie claim it).

I will spin a v3 with the check and the claim in reverse order. But I
think we should keep the pci_claim() call.

Agreed.

Thanks,
Lorenzo