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 v2 1/1] arm: acpi: pci-expender-bus: Make arm to support PXB-PCIE
Date: Tue, 18 Feb 2020 07:25:09 +0000 [thread overview]
Message-ID: <80a1d04e006249ada203e420c4e97cb2@huawei.com> (raw)
In-Reply-To: <20200217080640-mutt-send-email-mst@kernel.org>
> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Monday, February 17, 2020 9:09 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 v2 1/1] arm: acpi: pci-expender-bus: Make arm to support
> PXB-PCIE
>
> On Mon, Feb 17, 2020 at 07:18:18PM +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.
> > Under this circumstance, different io numas for differnt devices is
> > not possible, in order to present io numas to the guest, especially
> > for host pssthrough devices. PXB-PCIE is supproted by arm and certain
> > resource is allocated for each pxb-pcie in acpi table.
> >
> > Signed-off-by: miaoyubo <miaoyubo@huawei.com>
>
> A unit test would be nic.
>
Thanks for replying, I will add the unit test in patch V3.
> > ---
> > hw/arm/virt-acpi-build.c | 240 +++++++++++++++++++++++++++++-------
> ---
> > hw/pci-host/gpex.c | 4 +
> > include/hw/arm/virt.h | 1 +
> > 3 files changed, 184 insertions(+), 61 deletions(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c index
> > bd5f771e9b..fc11525042 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
> >
> > + method = aml_method("_CRS", 0, AML_NOTSERIALIZED);
> > + Aml *rbuf = aml_resource_template();
> > + aml_append(rbuf,
> > + aml_word_bus_number(AML_MIN_FIXED, AML_MAX_FIXED,
> AML_POS_DECODE,
> > + 0x0000, 0x0000, root_bus_limit, 0x0000,
> > + root_bus_limit + 1));
> > + aml_append(rbuf,
> > + aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED,
> AML_MAX_FIXED,
> > + AML_NON_CACHEABLE, AML_READ_WRITE, 0x0000,
> base_mmio,
> > + base_mmio + size_mmio - 1 - size_addr * count,
> > + 0x0000, size_mmio - size_addr * count));
> > + aml_append(rbuf,
> > + aml_dword_io(AML_MIN_FIXED, AML_MAX_FIXED,
> AML_POS_DECODE,
> > + AML_ENTIRE_RANGE, 0x0000, 0x0000,
> > + size_pio / 2 - 1 - size_io * count, base_pio,
> > + size_pio / 2 - size_io * count));
> > +
> > + if (use_highmem) {
> > + hwaddr base_mmio_high = memmap[VIRT_HIGH_PCIE_MMIO].base;
> > + hwaddr size_mmio_high = memmap[VIRT_HIGH_PCIE_MMIO].size;
> > +
> > + aml_append(rbuf,
> > + aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED,
> AML_MAX_FIXED,
> > + AML_NON_CACHEABLE, AML_READ_WRITE, 0x0000,
> > + base_mmio_high,
> > + base_mmio_high + size_mmio_high - 1 -
> > + size_addr * count,
> > + 0x0000, size_mmio_high - size_addr * count));
> > + }
> > +
> > + aml_append(method, aml_name_decl("RBUF", rbuf));
> > + aml_append(method, aml_return(rbuf));
> > + aml_append(dev, method);
> > +
> > + acpi_dsdt_add_pci_osc(dev, scope);
> >
> > Aml *dev_rp0 = aml_device("%s", "RP0");
> > aml_append(dev_rp0, aml_name_decl("_ADR", aml_int(0)));
>
>
> this will be easier to review if you first refactor existing code, then add pxb
> support on top.
>
Thanks for the suggestion, the next patch would separate this patch into two patches,
one is to refactor existing code and another one add pxb support.
> > @@ -744,7 +862,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> VirtMachineState *vms)
> > acpi_dsdt_add_virtio(scope, &memmap[VIRT_MMIO],
> > (irqmap[VIRT_MMIO] + ARM_SPI_BASE),
> NUM_VIRTIO_TRANSPORTS);
> > acpi_dsdt_add_pci(scope, memmap, (irqmap[VIRT_PCIE] +
> ARM_SPI_BASE),
> > - vms->highmem, vms->highmem_ecam);
> > + vms->highmem, vms->highmem_ecam, vms);
> > if (vms->acpi_dev) {
> > build_ged_aml(scope, "\\_SB."GED_DEVICE,
> > HOTPLUG_HANDLER(vms->acpi_dev), diff --git
> > a/hw/pci-host/gpex.c b/hw/pci-host/gpex.c index 0ca604dc62..2c18cdfec4
> > 100644
> > --- a/hw/pci-host/gpex.c
> > +++ b/hw/pci-host/gpex.c
> > @@ -36,6 +36,7 @@
> > #include "hw/qdev-properties.h"
> > #include "migration/vmstate.h"
> > #include "qemu/module.h"
> > +#include "hw/arm/virt.h"
> >
> >
> /**********************************************************
> ******************
> > * 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
> > 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));
>
>
> What does all this have to do with building on aarch64?
>
>
gpex.c is the public file for Generic PCI Express Bridge Emulation,
using aarch64 to avoid affect other architectures
> > diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index
> > 71508bf40c..cfc65dd19b 100644
> > --- a/include/hw/arm/virt.h
> > +++ b/include/hw/arm/virt.h
> > @@ -140,6 +140,7 @@ typedef struct {
> > DeviceState *gic;
> > DeviceState *acpi_dev;
> > Notifier powerdown_notifier;
> > + PCIBus *bus;
> > } VirtMachineState;
>
> Again one bus per machine? Pls give this field a better name and add some
> comments.
>
Not one bus, the bus include the root bus and all pxb-pcie buses.
it is pointer to the device objects. By go through the bus, we get the pxbs
defined and also the numa_node, the usage and the name is just the same with
X86.(also PCIBus *bus in PCMachineState) The comments would be add in next
patch ,And do u have any suggestion for the better name?
> >
> > #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM :
> > VIRT_PCIE_ECAM)
> > --
> > 2.19.1
> >
Regards,
Miao
prev parent reply other threads:[~2020-02-18 7:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 11:18 [RFC v2 0/1] pci_expander_brdige:acpi:Support pxb-pcie for ARM Yubo Miao
2020-02-17 11:18 ` [RFC v2 1/1] arm: acpi: pci-expender-bus: Make arm to support PXB-PCIE Yubo Miao
2020-02-17 13:08 ` Michael S. Tsirkin
2020-02-18 7:25 ` miaoyubo [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=80a1d04e006249ada203e420c4e97cb2@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).