All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>, linuxppc-dev@lists.ozlabs.org
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	Paul Mackerras <paulus@samba.org>,
	Thomas Huth <thuth@linux.vnet.ibm.com>
Subject: Re: [PATCH] pci-scan: Fix setting the limit
Date: Wed, 14 May 2014 15:22:44 +0530	[thread overview]
Message-ID: <87tx8soff7.fsf@abhimanyu.in.ibm.com> (raw)
In-Reply-To: <1399978118-10298-1-git-send-email-aik@ozlabs.ru>

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> PCI spec says that lower 20 bits are assumed 0xFFFFF. The existing code
> seems to get it right in pci-bridge-set-mem-limit.
>
> However pci-bridge-set-mem-base does not account 0xFFFFF and poison
> the limit. Since the limit is not stored anywhere in SLOF and only
> besides in the config space, it remains broken.
>
> This fixes pci-bridge-set-mem-base.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I have doubts this is the right fix as I tried to "fix"
> pci-bridge-set-mmio-base (while I am here) and it broke the guest.
>
> The problem I am fixing by this is that QEMU started as below is
> unable to initialize virtio-net device because there are overlapping
> virtio's BAR and bridge's "ranges" property. Note that virtio-net is
> attached to the PHB, not that additional bridge.
>
> /home/aik/qemu-system-ppc64 \
> -enable-kvm \
> -m 1024 \
> -machine pseries \
> -nographic \
> -vga none \
> -device pci-bridge,id=id0,bus=pci.0,addr=5.0,chassis_nr=7 \
> -netdev tap,id=id1,ifname=tap1,script=ifup.sh,downscript=ifdown.sh \
> -device virtio-net-pci,id=id2,netdev=id1 \
> -initrd 1.cpio \
> -kernel vml315rc3 \

The problem that I saw here is the brigde device does not have a
downstream pci device. Before probing, we are setting the ranges
property to the max limit, and the probe is done. Once the probe is over
we would update the ranges property. 

In this particular case, when we come to update the " ranges" property,
we do not have any range and we skip updating it. Because of this the
old max range property remains there, which is not correct.

Something like the below solves this particular problem. But what would
happen when someone tries to hotplug a pci device to this bridge, will
the pci-hotplug code take care of updating the ranges property?


diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs
index f88a571..f5e934d 100644
--- a/slof/fs/pci-properties.fs
+++ b/slof/fs/pci-properties.fs
@@ -410,6 +410,7 @@
         dup IF                          \ IF any space present (propsize>0)
                 s" ranges" property     \ | write it into the device tree
         ELSE                            \ ELSE
+               s" " s" ranges" property
                 2drop                   \ | forget the properties
         THEN                            \ FI
         drop                            \ forget the address

So I do not see the problem when there is a device allocated downstream
to the pci-bridge.

Regards
Nikunj

      parent reply	other threads:[~2014-05-14  9:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 10:48 [PATCH] pci-scan: Fix setting the limit Alexey Kardashevskiy
2014-05-13 11:16 ` Alexey Kardashevskiy
2014-05-14  9:52 ` Nikunj A Dadhania [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tx8soff7.fsf@abhimanyu.in.ibm.com \
    --to=nikunj@linux.vnet.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=thuth@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.