From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Chien <jason.chien@sifive.com>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
"Peter Maydell" <peter.maydell@linaro.org>,
"Andrey Smirnov" <andrew.smirnov@gmail.com>,
"Greg Kurz" <groug@kaod.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Igor Mammedov" <imammedo@redhat.com>,
qemu-arm@nongnu.org
Subject: Re: [PATCH] hw/pci-host: Allow extended config space access for Designware PCIe host
Date: Thu, 10 Aug 2023 13:43:56 -0400 [thread overview]
Message-ID: <20230810134315-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CADr__8ohzCfEYkXz+6u06hDQZNM8q9Cp9eehtcBFhdKtnySPBA@mail.gmail.com>
On Fri, Aug 11, 2023 at 01:22:08AM +0800, Jason Chien wrote:
> As far as I know, the order issue is caused by nested device realization. In
> this case, realizing TYPE_DESIGNWARE_PCIE_HOST will also
> realize TYPE_DESIGNWARE_PCIE_ROOT(see designware_pcie_host_realize()).
> device_set_realized() is the function that realizing a device must go through,
> and this function first realizes the device by dc->realize() and then realizes
> the device's child bus by qbus_realize(). Whether there is any child bus of the
> device may depend on dc->realize(). The realization flow will be like a
> recursive call to device_set_realized(). More precisely, the flow in this case
> is: qdev_realize() --> ... --> FIRST device_set_realized() --> FIRST dc->
> realize() --> ... --> designware_pcie_host_realize() --> qdev_realize() --> ...
> --> SECOND device_set_realized() --> SECOND dc->realize() --> ... -->
> designware_pcie_root_realize() --> ...--> back to the SECOND
> device_set_realized() --> SECOND qbus_realize() the CHILD bus "dw-pcie" --> ...
> --> back to the FIRST device_set_realized() --> FIRST qbus_realize() the PARENT
> bus "pcie".
>
> I also found this patch that solves the same bus issue.
Which patch?
> Do you have any suggestions on the order of realization? Thanks!
I see. It's not easy to fix. Worth thinking about but I guess your
patch is ok for now.
> On Thu, Aug 10, 2023 at 5:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Aug 09, 2023 at 10:22:50AM +0000, Jason Chien wrote:
> > In pcie_bus_realize(), a root bus is realized as a PCIe bus and a
> non-root
> > bus is realized as a PCIe bus if its parent bus is a PCIe bus. However,
> > the child bus "dw-pcie" is realized before the parent bus "pcie" which is
> > the root PCIe bus. Thus, the extended configuration space is not
> accessible
> > on "dw-pcie". The issue can be resolved by adding the
> > PCI_BUS_EXTENDED_CONFIG_SPACE flag to "pcie" before "dw-pcie" is
> realized.
> >
> > Signed-off-by: Jason Chien <jason.chien@sifive.com>
>
> I think we should fix the order of initialization rather than
> hack around it.
>
> > ---
> > hw/pci-host/designware.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
> > index 9e183caa48..388d252ee2 100644
> > --- a/hw/pci-host/designware.c
> > +++ b/hw/pci-host/designware.c
> > @@ -694,6 +694,7 @@ static void designware_pcie_host_realize(DeviceState
> *dev, Error **errp)
> > &s->pci.io,
> > 0, 4,
> > TYPE_PCIE_BUS);
> > + pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
> >
> > memory_region_init(&s->pci.address_space_root,
> > OBJECT(s),
> > --
> > 2.17.1
>
>
next prev parent reply other threads:[~2023-08-10 17:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 10:22 [PATCH] hw/pci-host: Allow extended config space access for Designware PCIe host Jason Chien
2023-08-09 21:24 ` Michael S. Tsirkin
2023-08-10 17:22 ` Jason Chien
2023-08-10 17:43 ` Michael S. Tsirkin [this message]
2023-08-10 17:46 ` Jason Chien
2023-08-10 17:51 ` Michael S. Tsirkin
2023-08-11 9:55 ` Peter Maydell
2023-08-11 14:06 ` Peter Maydell
2023-08-12 5:37 ` Jason Chien
2023-08-11 6:46 ` Frank Chang
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=20230810134315-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=andrew.smirnov@gmail.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=jason.chien@sifive.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
/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.