From: miaoyubo <miaoyubo@huawei.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"imammedo@redhat.com" <imammedo@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Xiexiangyou <xiexiangyou@huawei.com>,
"shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>
Subject: RE: [RFC v3 2/3] acpi:pci-expender-bus: Add pxb support for arm
Date: Sat, 22 Feb 2020 09:37:38 +0000 [thread overview]
Message-ID: <744bd79fef954750b387e1d99ee43d3e@huawei.com> (raw)
In-Reply-To: <20200221061402-mutt-send-email-mst@kernel.org>
> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Friday, February 21, 2020 7:18 PM
> To: miaoyubo <miaoyubo@huawei.com>
> Cc: peter.maydell@linaro.org; shannon.zhaosl@gmail.com; Xiexiangyou
> <xiexiangyou@huawei.com>; imammedo@redhat.com;
> qemu-devel@nongnu.org
> Subject: Re: [RFC v3 2/3] acpi:pci-expender-bus: Add pxb support for arm
>
> On Fri, Feb 21, 2020 at 02:35:11PM +0800, Yubo Miao wrote:
> > From: miaoyubo <miaoyubo@huawei.com>
> >
> > Currently virt machine is not supported by pxb-pcie, and only one main
> > host bridge described in ACPI tables.
> > In this patch,PXB-PCIE is supproted by arm and certain resource is
> > allocated for each pxb-pcie in acpi table.
> > The resource for the main host bridge is also reallocated.
> >
> > Signed-off-by: miaoyubo <miaoyubo@huawei.com>
> > ---
> > hw/arm/virt-acpi-build.c | 125
> +++++++++++++++++++++++++++++++++++----
> > hw/pci-host/gpex.c | 4 ++
> > include/hw/arm/virt.h | 7 +++
> > 3 files changed, 125 insertions(+), 11 deletions(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c index
> > 0540234b8a..2c1e0d2aaa 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -49,6 +49,8 @@
> > #include "kvm_arm.h"
> > #include "migration/vmstate.h"
> >
> > +#include "hw/arm/virt.h"
> > +#include "hw/pci/pci_bus.h"
> > #define ARM_SPI_BASE 32
> >
> > static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus) @@ -271,19
> > +273,117 @@ static void acpi_dsdt_add_pci_osc(Aml *dev, Aml *scope) }
> >
> > static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry
> *memmap,
> > - uint32_t irq, bool use_highmem, bool
> highmem_ecam)
> > + uint32_t irq, bool use_highmem, bool
> highmem_ecam,
> > + VirtMachineState *vms)
> > {
> > int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> > - Aml *method, *crs;
> > + Aml *method, *dev, *crs;
> > + int count = 0;
> > hwaddr base_mmio = memmap[VIRT_PCIE_MMIO].base;
> > hwaddr size_mmio = memmap[VIRT_PCIE_MMIO].size;
> > hwaddr base_pio = memmap[VIRT_PCIE_PIO].base;
> > hwaddr size_pio = memmap[VIRT_PCIE_PIO].size;
> > hwaddr base_ecam = memmap[ecam_id].base;
> > hwaddr size_ecam = memmap[ecam_id].size;
> > + /*
> > + * 0x600000 would be enough for pxb device
> > + * if it is too small, there is no enough space
> > + * for a pcie device plugged in a pcie-root port
> > + */
> > + hwaddr size_addr = 0x600000;
> > + hwaddr size_io = 0x4000;
> > int nr_pcie_buses = size_ecam / PCIE_MMCFG_SIZE_MIN;
> > + int root_bus_limit = 0xFF;
>
> what's this?
>
Thanks for replying.
This is used to define the bus numbers for the main host bridge,
If no pxb-pcie is defined, the bus number for the main host bridge
would range form 0 to 255.
> > + PCIBus *bus = NULL;
> > + bus = VIRT_MACHINE(vms)->bus;
>
> So just move assignment as part of declaration.
>
Thanks for the suggestion!
> > +
> > + if (bus) {
> > + QLIST_FOREACH(bus, &bus->child, sibling) {
> > + uint8_t bus_num = pci_bus_num(bus);
> > + uint8_t numa_node = pci_bus_numa_node(bus);
> > +
> > + if (!pci_bus_is_root(bus)) {
> > + continue;
> > + }
> > + if (bus_num < root_bus_limit) {
> > + root_bus_limit = bus_num - 1;
>
> what is this doing? manually coded up MIN?
>
This coded up the MIN of busNr defined in pxb-pcie devices,
and the Min busNr-1 would be the MAX bus Number for the main host bridge.
For example, if one pxb-pcie with busNr 128(which is 80) defined,
The bus for the main host bridge would be 0-7F, and the bus for pxb-pcie
would be 80-81(just allocate two buses,keep the same with X86).
If pxb-pcie is not defined, the bus for main host bridge would be 0-FF.
> > + }
> > + count++;
> > + dev = aml_device("PC%.02X", bus_num);
> > + aml_append(dev, aml_name_decl("_HID",
> aml_string("PNP0A08")));
> > + aml_append(dev, aml_name_decl("_CID",
> aml_string("PNP0A03")));
> > + aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > + aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
> > + aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
> > + aml_append(dev, aml_name_decl("_BBN",
> aml_int(bus_num)));
> > + aml_append(dev, aml_name_decl("_UID",
> aml_int(bus_num)));
> > + aml_append(dev, aml_name_decl("_STR", aml_unicode("pxb
> Device")));
> > + if (numa_node != NUMA_NODE_UNASSIGNED) {
> > + method = aml_method("_PXM", 0,
> AML_NOTSERIALIZED);
> > + aml_append(method,
> aml_return(aml_int(numa_node)));
> > + aml_append(dev, method);
> > + }
> > +
> > * GPEX host
> > @@ -98,6 +99,9 @@ static void gpex_host_realize(DeviceState *dev, Error
> **errp)
> > pci_swizzle_map_irq_fn, s,
> &s->io_mmio,
> > &s->io_ioport, 0, 4,
> > TYPE_PCIE_BUS);
> >
> > +#ifdef __aarch64__
> > + VIRT_MACHINE(qdev_get_machine())->bus = pci->bus; #endif
>
> I'm repeating myself but - what does this have to do with building on
> __aarch64__?
>
I would move this into machvirt_init, therefore, the __aarch64__ is not needed.
> > qdev_set_parent_bus(DEVICE(&s->gpex_root), BUS(pci->bus));
> > pci_bus_set_route_irq_fn(pci->bus, gpex_route_intx_pin_to_irq);
> > qdev_init_nofail(DEVICE(&s->gpex_root));
> > diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index
> > 71508bf40c..9accaf2b1b 100644
> > --- a/include/hw/arm/virt.h
> > +++ b/include/hw/arm/virt.h
> > @@ -140,6 +140,13 @@ typedef struct {
> > DeviceState *gic;
> > DeviceState *acpi_dev;
> > Notifier powerdown_notifier;
> > + /*
> > + * pointer to devices and objects
> > + * Via going through the bus, all
> > + * pci devices and related objectes
> > + * could be gained.
> > + * */
> > + PCIBus *bus;
>
> That comment doesn't really tell me what this is.
> Is this the root bus?
> With an extender, don't we have lots of roots?
>
>
Yes, this is the root bus.(The pci.0 or pcie.0)
The main root is pci.0 or pcie.0, the extender plays the role of root for devices
plugged on it. For the extender, there is only one root,pci.0 or pcie.0.
But for devices like pcie-root-port, they could also regard pxb-pcie as root.
Hope this solve your question.
> > } VirtMachineState;
> >
> > #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM :
> > VIRT_PCIE_ECAM)
> > --
> > 2.19.1
> >
Regards,
Miao
next prev parent reply other threads:[~2020-02-22 9:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 6:35 [RFC v3 0/3] pci_expander_brdige:acpi:Support pxb-pcie for ARM Yubo Miao
2020-02-21 6:35 ` [RFC v3 1/3] acpi:Extract two APIs from acpi_dsdt_add_pci Yubo Miao
2020-02-21 6:35 ` [RFC v3 2/3] acpi:pci-expender-bus: Add pxb support for arm Yubo Miao
2020-02-21 11:17 ` Michael S. Tsirkin
2020-02-22 9:37 ` miaoyubo [this message]
2020-02-21 6:35 ` [RFC v3 3/3] ACPI/unit-test: Add a new test for pxb-pcie " Yubo Miao
2020-02-21 11:19 ` Michael S. Tsirkin
2020-02-22 9:40 ` miaoyubo
2020-02-23 21:25 ` Michael S. Tsirkin
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=744bd79fef954750b387e1d99ee43d3e@huawei.com \
--to=miaoyubo@huawei.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=xiexiangyou@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).