[SLOF] [PATCH slof] pci: Put non-prefetchable 64bit BARs into 32bit MMIO window

David Gibson david at gibson.dropbear.id.au
Wed Apr 26 12:11:16 AEST 2017


On Tue, Apr 25, 2017 at 01:00:18PM +0200, Laurent Vivier wrote:
> On 25/04/2017 12:36, Laurent Vivier wrote:
> > On 24/04/2017 05:01, Alexey Kardashevskiy wrote:
> >> At the moment 64bit non-prefetchable BARs of devices behind PCI p2p
> >> bridge go to a 64bit prefetchable windows which is not correct and
> >> causes linux guests to fail to ioremap() such resources.
> >>
> >> This moves 64bit non-prefetchable BARs 32bit non-prefetchable window.
> >>
> >> Note that this does not make distinction between P2P and PHB so
> >> from now on XHCI BARs will be allocated from 32bit MMIO space.
> >> However since most 64bit-MMIO-capable devices have prefetchable BARs,
> >> and XHCI BAR is just 4K (so it is unlikely to cause any space problems),
> >> this should not affect usual behavior.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik at ozlabs.ru>
> >> ---
> >>
> >> This fixes QEMU's XHCI when it is put on a P2P PCI bridge.
> >>
> >> There is a little naming confusion as it may look like the patch
> >> is changing assignment for all 64bit BAR but it does not as:
> >> - "mmio" is used for non-prefetchable memory,
> >> - "mem" is used for prefetchable memory.
> >> ---
> >>  slof/fs/pci-properties.fs | 6 +-----
> >>  1 file changed, 1 insertion(+), 5 deletions(-)
> >>
> >> diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs
> >> index e6fd843..8594e5d 100644
> >> --- a/slof/fs/pci-properties.fs
> >> +++ b/slof/fs/pci-properties.fs
> >> @@ -166,11 +166,7 @@
> >>  \ Setup a non-prefetchable 64bit BAR and return its size
> >>  : assign-mmio64-bar ( bar-addr -- 8 )
> >>          dup pci-bar-size-mem64          \ fetch size
> >> -        pci-next-mem64 @ 0 = IF          \ Check if we have 64-bit memory range
> >> -	    pci-next-mmio
> >> -	ELSE
> >> -	    pci-next-mem64              \ for board-qemu we will use same range
> >> -	THEN
> >> +        pci-next-mmio
> >>          assign-bar-value64              \ and set it all
> >>  ;
> >>  
> >>
> > Tested-by: Laurent Vivier <lvivier at redhat.com>
> 
> This fixes the problem when the BAR is mem, not when it is io.
> 
> I have the same problem as with XHCI as with virtio-blk devices behind a
> pci bridge, and the error is:
> 
> ...
> PCI: Cannot allocate resource region 0 of device 0000:01:01.0, will remap
> ...
> virtio-pci 0000:01:01.0: can't enable device: BAR 0 [io  size 0x0040]
> not assigned
> ...
> 
> And this patch doesn't fix it.
> 
> XHCI error was:
> 
> PCI: Cannot allocate resource region 0 of device 0000:01:03.0, will remap
> ...
> xhci_hcd 0000:01:03.0: can't enable device: BAR 0 [mem size 0x00004000]
> not assigned

I don't think the problem for virtio can be quite analagous.  Legacy
IO windows don't have either the prefetchable / no-prefetchable or the
32-bit / 64-bit distinctions that memory windows do.  So while there
certainly could be a bug in assigning IO windows under bridges, I
think it's independent from this bug.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20170426/3436c70a/attachment.sig>


More information about the SLOF mailing list