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 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.