From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
David Woodhouse <dwmw@amazon.co.uk>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>,
Peter Maydell <peter.maydell@linaro.org>,
Anthony Perard <anthony.perard@citrix.com>,
Paul Durrant <paul@xen.org>,
"open list:ARM TCG CPUs" <qemu-arm@nongnu.org>,
"open list:X86 Xen CPUs" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 6/6] xen_arm: Add virtual PCIe host bridge support
Date: Fri, 24 Nov 2023 15:47:45 +0000 [thread overview]
Message-ID: <878r6nw3tr.fsf@epam.com> (raw)
In-Reply-To: <20231124133028.72ba1d6e@imammedo.users.ipa.redhat.com>
Hi Igor,
Thank you for the review,
Igor Mammedov <imammedo@redhat.com> writes:
> On Tue, 21 Nov 2023 22:10:28 +0000
> Volodymyr Babchuk <Volodymyr_Babchuk@epam.com> wrote:
>
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> The bridge is needed for virtio-pci support, as QEMU can emulate the
>> whole bridge with any virtio-pci devices connected to it.
>>
>> This patch provides a flexible way to configure PCIe brige resources
>> with xenstore. We made this for several reasons:
>>
>> - We don't want to clash with vPCI devices, so we need information
>> from Xen toolstack on which PCI bus to use.
>> - The guest memory layout that describes these resources is not stable
>> and may vary between guests, so we cannot rely on static resources
>> to be always the same for both ends.
>> - Also the device-models which run in different domains and serve
>> virtio-pci devices for the same guest should use different host
>> bridge resources for Xen to distinguish. The rule for the guest
>> device-tree generation is one PCI host bridge per backend domain.
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>
>> ---
>>
>> Changes from v1:
>>
>> - Renamed virtio_pci_host to pcie_host entries in XenStore, because
>> there is nothing specific to virtio-pci: any PCI device can be
>> emulated via this newly created bridge.
>> ---
>> hw/arm/xen_arm.c | 186 ++++++++++++++++++++++++++++++++++++
>> hw/xen/xen-hvm-common.c | 9 +-
>> include/hw/xen/xen_native.h | 8 +-
>> 3 files changed, 200 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
>> index b9c3ae14b6..d506d55d0f 100644
>> --- a/hw/arm/xen_arm.c
>> +++ b/hw/arm/xen_arm.c
>> @@ -22,6 +22,7 @@
>> */
>>
>> #include "qemu/osdep.h"
>> +#include "qemu/cutils.h"
>> #include "qemu/error-report.h"
>> #include "qapi/qapi-commands-migration.h"
>> #include "qapi/visitor.h"
>> @@ -34,6 +35,9 @@
>> #include "hw/xen/xen-hvm-common.h"
>> #include "sysemu/tpm.h"
>> #include "hw/xen/arch_hvm.h"
>> +#include "exec/address-spaces.h"
>> +#include "hw/pci-host/gpex.h"
>> +#include "hw/virtio/virtio-pci.h"
>>
>> #define TYPE_XEN_ARM MACHINE_TYPE_NAME("xenpvh")
>> OBJECT_DECLARE_SIMPLE_TYPE(XenArmState, XEN_ARM)
>> @@ -58,6 +62,11 @@ struct XenArmState {
>> struct {
>> uint64_t tpm_base_addr;
>> } cfg;
>> +
>> + MemMapEntry pcie_mmio;
>> + MemMapEntry pcie_ecam;
>> + MemMapEntry pcie_mmio_high;
>> + int pcie_irq;
>> };
>>
>> static MemoryRegion ram_lo, ram_hi;
>> @@ -73,6 +82,7 @@ static MemoryRegion ram_lo, ram_hi;
>> #define NR_VIRTIO_MMIO_DEVICES \
>> (GUEST_VIRTIO_MMIO_SPI_LAST - GUEST_VIRTIO_MMIO_SPI_FIRST)
>>
>> +/* TODO It should be xendevicemodel_set_pci_intx_level() for PCI interrupts. */
>> static void xen_set_irq(void *opaque, int irq, int level)
>> {
>> if (xendevicemodel_set_irq_level(xen_dmod, xen_domid, irq, level)) {
>> @@ -129,6 +139,176 @@ static void xen_init_ram(MachineState *machine)
>> }
>> }
>>
>> +static void xen_create_pcie(XenArmState *xam)
>> +{
>> + MemoryRegion *mmio_alias, *mmio_alias_high, *mmio_reg;
>> + MemoryRegion *ecam_alias, *ecam_reg;
>> + DeviceState *dev;
>> + int i;
>> +
>> + dev = qdev_new(TYPE_GPEX_HOST);
>> + sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
>> +
>> + /* Map ECAM space */
>> + ecam_alias = g_new0(MemoryRegion, 1);
>> + ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0);
>> + memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam",
>> + ecam_reg, 0, xam->pcie_ecam.size);
>> + memory_region_add_subregion(get_system_memory(), xam->pcie_ecam.base,
>> + ecam_alias);
>> +
>> + /* Map the MMIO space */
>> + mmio_alias = g_new0(MemoryRegion, 1);
>> + mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1);
>> + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio",
>> + mmio_reg,
>> + xam->pcie_mmio.base,
>> + xam->pcie_mmio.size);
>> + memory_region_add_subregion(get_system_memory(), xam->pcie_mmio.base,
>> + mmio_alias);
>> +
>> + /* Map the MMIO_HIGH space */
>> + mmio_alias_high = g_new0(MemoryRegion, 1);
>> + memory_region_init_alias(mmio_alias_high, OBJECT(dev), "pcie-mmio-high",
>> + mmio_reg,
>> + xam->pcie_mmio_high.base,
>> + xam->pcie_mmio_high.size);
>> + memory_region_add_subregion(get_system_memory(), xam->pcie_mmio_high.base,
>> + mmio_alias_high);
>> +
>> + /* Legacy PCI interrupts (#INTA - #INTD) */
>> + for (i = 0; i < GPEX_NUM_IRQS; i++) {
>> + qemu_irq irq = qemu_allocate_irq(xen_set_irq, NULL,
>> + xam->pcie_irq + i);
>> +
>> + sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, irq);
>> + gpex_set_irq_num(GPEX_HOST(dev), i, xam->pcie_irq + i);
>> + }
>> +
>
>> + DPRINTF("Created PCIe host bridge\n");
> replace DPRINTFs with trace_foo(), see 885f380f7be for example
>
>> +}
>> +
>> +static bool xen_read_pcie_prop(XenArmState *xam, unsigned int xen_domid,
>> + const char *prop_name, unsigned long *data)
>> +{
>> + char path[128], *value = NULL;
>> + unsigned int len;
>> + bool ret = true;
>> +
>> + snprintf(path, sizeof(path), "device-model/%d/pcie_host/%s",
>> + xen_domid, prop_name);
>
> try to avoid usage of snprintf() in series
> see d2fe2264679 as an example
>
This whole function will be dropped in the next version.
>> + value = xs_read(xam->state->xenstore, XBT_NULL, path, &len);
> maybe use g_autofree
I am not sure if this is a good idea, as xs_read() is provided by an
external library which uses plain old malloc().
>> xen_create_virtio_mmio_devices(xam);
>> + if (!xen_get_pcie_params(xam)) {
>> + xen_create_pcie(xam);
>> + } else {
>> + DPRINTF("PCIe host bridge is not available,"
>> + "only virtio-mmio can be used\n");
>
> so if something went wrong, it will be just ignored.
> Is it really expected behavior?
>
In the new version I reworked this section. Now we have 3 possible
outcomes:
1. No PCIe config was provided at all. This is fine, as user don't want
to use PCIe.
2. Full PCIe config was provided. We continue to creating the PCIe bridge.
3. Partial config was provided. This is an error and we exit.
--
WBR, Volodymyr
prev parent reply other threads:[~2023-11-24 15:48 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 22:10 [PATCH v2 0/6] xen-arm: add support for virtio-pci Volodymyr Babchuk
2023-11-21 22:10 ` [PATCH v2 1/6] hw/xen: Set XenBackendInstance in the XenDevice before realizing it Volodymyr Babchuk
2023-11-22 15:54 ` Paul Durrant
2023-11-22 17:05 ` Paul Durrant
2023-11-22 22:44 ` Woodhouse, David
2023-11-22 22:44 ` Woodhouse, David via
2023-11-22 23:49 ` Volodymyr Babchuk
2023-11-22 23:55 ` Woodhouse, David
2023-11-22 23:55 ` Woodhouse, David via
2023-11-22 22:56 ` Volodymyr Babchuk
2023-11-22 23:04 ` David Woodhouse
2023-11-23 9:29 ` Paul Durrant
2023-11-21 22:10 ` [PATCH v2 3/6] xen: xenstore: add possibility to preserve owner Volodymyr Babchuk
2023-11-22 17:07 ` Paul Durrant
2023-11-22 22:28 ` Stefano Stabellini
2023-11-22 23:01 ` David Woodhouse
2023-11-22 23:03 ` Volodymyr Babchuk
2023-11-23 1:19 ` Volodymyr Babchuk
2023-11-21 22:10 ` [PATCH v2 2/6] xen: backends: touch some XenStore nodes only if device Volodymyr Babchuk
2023-11-22 11:07 ` Philippe Mathieu-Daudé
2023-11-22 22:49 ` Volodymyr Babchuk
2023-11-22 23:19 ` David Woodhouse
2023-11-22 17:03 ` Paul Durrant
2023-11-22 22:46 ` Woodhouse, David
2023-11-22 22:46 ` Woodhouse, David via
2023-11-22 22:50 ` Volodymyr Babchuk
2023-11-21 22:10 ` [PATCH v2 5/6] xen_arm: Set mc->max_cpus to GUEST_MAX_VCPUS in xen_arm_init() Volodymyr Babchuk
2023-11-22 11:10 ` Philippe Mathieu-Daudé
2023-11-24 12:04 ` Igor Mammedov
2023-11-21 22:10 ` [PATCH v2 4/6] xen_pvdev: Do not assume Dom0 when creating a directory Volodymyr Babchuk
2023-11-22 17:11 ` Paul Durrant
2023-11-22 22:29 ` Stefano Stabellini
2023-11-22 23:03 ` David Woodhouse
2023-11-22 23:09 ` Stefano Stabellini
2023-11-22 23:11 ` David Woodhouse
2023-11-22 23:20 ` Stefano Stabellini
2023-11-22 23:46 ` Volodymyr Babchuk
2023-11-23 0:07 ` Volodymyr Babchuk
2023-11-23 9:28 ` Paul Durrant
2023-11-23 10:45 ` David Woodhouse
2023-11-23 11:43 ` Volodymyr Babchuk
2023-11-23 11:51 ` David Woodhouse
2023-11-23 11:54 ` Volodymyr Babchuk
2023-11-23 11:57 ` David Woodhouse
2023-11-23 12:17 ` Volodymyr Babchuk
2023-11-23 12:27 ` David Woodhouse
2023-11-23 12:54 ` Paul Durrant
2023-11-24 0:24 ` Volodymyr Babchuk
2023-11-24 12:56 ` Alex Bennée
2023-11-21 22:10 ` [PATCH v2 6/6] xen_arm: Add virtual PCIe host bridge support Volodymyr Babchuk
2023-11-22 22:39 ` Stefano Stabellini
2023-11-22 23:44 ` Vikram Garhwal
2023-11-23 0:11 ` Volodymyr Babchuk
2023-11-24 12:30 ` Igor Mammedov
2023-11-24 15:47 ` Volodymyr Babchuk [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=878r6nw3tr.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=Oleksandr_Tyshchenko@epam.com \
--cc=anthony.perard@citrix.com \
--cc=dwmw@amazon.co.uk \
--cc=imammedo@redhat.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.