qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: qemu-devel@nongnu.org, anthony@xenproject.org, paul@xen.org,
	peter.maydell@linaro.org, alex.bennee@linaro.org,
	xenia.ragiadakou@amd.com, jason.andryuk@amd.com,
	edgar.iglesias@amd.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 08/10] hw/xen: pvh-common: Add support for creating PCIe/GPEX
Date: Wed, 14 Aug 2024 17:26:08 +0200	[thread overview]
Message-ID: <ZrzMkI5jGUtXU2qA@zapote> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2408121822370.298534@ubuntu-linux-20-04-desktop>

On Mon, Aug 12, 2024 at 06:48:37PM -0700, Stefano Stabellini wrote:
> On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
> > 
> > Add support for optionally creating a PCIe/GPEX controller.
> > 
> > Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
> > ---
> >  hw/xen/xen-pvh-common.c         | 66 +++++++++++++++++++++++++++++++++
> >  include/hw/xen/xen-pvh-common.h | 10 ++++-
> >  2 files changed, 75 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c
> > index 69a2dbdb6d..b1432e4bd9 100644
> > --- a/hw/xen/xen-pvh-common.c
> > +++ b/hw/xen/xen-pvh-common.c
> > @@ -120,6 +120,59 @@ static void xen_enable_tpm(XenPVHCommonState *s)
> >  }
> >  #endif
> >  
> > +static void xen_set_pci_intx_irq(void *opaque, int irq, int level)
> > +{
> > +    if (xen_set_pci_intx_level(xen_domid, 0, 0, 0, irq, level)) {
> 
> Looking at the implementation of XEN_DMOP_set_pci_intx_level in
> xen/arch/x86/hvm/dm.c, it looks like the device parameter of
> xen_set_pci_intx_level is required?

Yes, by setting device = 0, we're bypassing the irq swizzling in Xen.
I'll try to clarify below.


> 
> 
> > +        error_report("xendevicemodel_set_pci_intx_level failed");
> > +    }
> > +}
> > +
> > +static inline void xenpvh_gpex_init(XenPVHCommonState *s,
> > +                                    MemoryRegion *sysmem,
> > +                                    hwaddr ecam_base, hwaddr ecam_size,
> > +                                    hwaddr mmio_base, hwaddr mmio_size,
> > +                                    hwaddr mmio_high_base,
> > +                                    hwaddr mmio_high_size,
> > +                                    int intx_irq_base)
> > +{
> > +    MemoryRegion *ecam_reg;
> > +    MemoryRegion *mmio_reg;
> > +    DeviceState *dev;
> > +    int i;
> > +
> > +    object_initialize_child(OBJECT(s), "gpex", &s->pci.gpex,
> > +                            TYPE_GPEX_HOST);
> > +    dev = DEVICE(&s->pci.gpex);
> > +    sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
> > +
> > +    ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0);
> > +    memory_region_add_subregion(sysmem, ecam_base, ecam_reg);
> 
> I notice we don't use ecam_size anywhere? Is that because the size is
> standard?

Yes. we could remove the size property, having it slightly simplifies the
prop setting code (keeping these memmap prop-pairs alike) but it's not a big deal.

> 
> 
> > +    mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1);
> > +
> > +    if (mmio_size) {
> > +        memory_region_init_alias(&s->pci.mmio_alias, OBJECT(dev), "pcie-mmio",
> > +                                 mmio_reg, mmio_base, mmio_size);
> > +        memory_region_add_subregion(sysmem, mmio_base, &s->pci.mmio_alias);
> > +    }
> > +
> > +    if (mmio_high_size) {
> > +        memory_region_init_alias(&s->pci.mmio_high_alias, OBJECT(dev),
> > +                "pcie-mmio-high",
> > +                mmio_reg, mmio_high_base, mmio_high_size);
> > +        memory_region_add_subregion(sysmem, mmio_high_base,
> > +                &s->pci.mmio_high_alias);
> > +    }
> > +
> > +    for (i = 0; i < GPEX_NUM_IRQS; i++) {
> > +        qemu_irq irq = qemu_allocate_irq(xen_set_pci_intx_irq, s, i);
> > +
> > +        sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, irq);
> > +        gpex_set_irq_num(GPEX_HOST(dev), i, intx_irq_base + i);
> > +        xen_set_pci_link_route(i, intx_irq_base + i);
> 
> xen_set_pci_link_route is not currently implemented on ARM?
> 
> Looking at hw/i386/pc_piix.c:piix_intx_routing_notifier_xen it seems
> that the routing is much more complex over there. But looking at other
> machines that use GPEX such as hw/arm/virt.c it looks like the routing
> is straightforward the same way as in this patch.
> 
> I thought that PCI interrupt pin swizzling was required, but maybe not ?
> 
> It is totally fine if we do something different, simpler, than
> hw/i386/pc_piix.c:piix_intx_routing_notifier_xen. I just want to make
> sure that things remain consistent between ARM and x86, and also between
> Xen and QEMU view of virtual PCI interrupt routing.
>

Good questions. The following is the way I understand things but I may
ofcourse be wrong.

Yes, we're doing things differently than hw/i386/pc_piix.c mainly
because we're using the GPEX PCIe host bridge with it's internal
standard swizzling down to 4 INTX interrupts. Similar to microvm and
the ARM virt machine.

The swizzling for the GPEX is done inside the GPEX model and it's
described by xl in the ACPI tables for PVH guests. We don't want
Xen to do any additional swizzling in xen_set_pci_intx_level(), hence
device=0.

I haven't plumbed the GPEX connectinos for ARM yet but I think we could
simply call xendevicemodel_set_irq_level() and not use the pci_intx
calls that aren't implement (we wouldn't need them).

For x86/pvh, I wonder if we should be using xen_set_pci_intx_level() /
xen_set_pci_link_route() or some other API? since we're basically
bypassing things?
In one of the first implementations we used set_isa_irq_level() but
that call only reaches into irqs < 16 so it messed things up.

Does any one have any better ideas or suggestions?

Cheers,
Edgar


  reply	other threads:[~2024-08-14 15:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-12 13:05 [PATCH v1 00/10] xen: pvh: Partial QOM:fication with new x86 PVH machine Edgar E. Iglesias
2024-08-12 13:05 ` [PATCH v1 01/10] MAINTAINERS: Add docs/system/arm/xenpvh.rst Edgar E. Iglesias
2024-08-13  1:45   ` Stefano Stabellini
2024-08-12 13:05 ` [PATCH v1 02/10] hw/arm: xenpvh: Update file header to use SPDX Edgar E. Iglesias
2024-08-13  1:45   ` Stefano Stabellini
2024-08-12 13:05 ` [PATCH v1 03/10] hw/arm: xenpvh: Tweak machine description Edgar E. Iglesias
2024-08-13  1:45   ` Stefano Stabellini
2024-08-12 13:05 ` [PATCH v1 04/10] hw/arm: xenpvh: Add support for SMP guests Edgar E. Iglesias
2024-08-13  1:47   ` Stefano Stabellini
2024-08-13 17:02     ` Edgar E. Iglesias
2024-08-13 17:20       ` Andrew Cooper
2024-08-13 22:52       ` Stefano Stabellini
2024-08-14 11:49         ` Edgar E. Iglesias
2024-08-15  0:30           ` Stefano Stabellini
2024-08-16 10:39             ` Edgar E. Iglesias
2024-08-16 16:53               ` Stefano Stabellini
2024-08-16 22:58                 ` Jason Andryuk
2024-08-20 14:13                   ` Edgar E. Iglesias
2024-08-12 13:06 ` [PATCH v1 05/10] hw/arm: xenpvh: Break out a common PVH module Edgar E. Iglesias
2024-08-13  1:47   ` Stefano Stabellini
2024-08-14 12:03     ` Edgar E. Iglesias
2024-08-12 13:06 ` [PATCH v1 06/10] hw/arm: xenpvh: Rename xen_arm.c -> xen-pvh.c Edgar E. Iglesias
2024-08-13  1:48   ` Stefano Stabellini
2024-08-12 13:06 ` [PATCH v1 07/10] hw/arm: xenpvh: Reverse virtio-mmio creation order Edgar E. Iglesias
2024-08-13  1:48   ` Stefano Stabellini
2024-08-12 13:06 ` [PATCH v1 08/10] hw/xen: pvh-common: Add support for creating PCIe/GPEX Edgar E. Iglesias
2024-08-13  1:48   ` Stefano Stabellini
2024-08-14 15:26     ` Edgar E. Iglesias [this message]
2024-08-15  0:29       ` Stefano Stabellini
2024-08-12 13:06 ` [PATCH v1 09/10] hw/i386/xen: Add a Xen PVH x86 machine Edgar E. Iglesias
2024-08-13  1:48   ` Stefano Stabellini
2024-08-14 15:50     ` Edgar E. Iglesias
2024-08-15  0:19       ` Stefano Stabellini
2024-08-12 13:06 ` [PATCH v1 10/10] docs/system/i386: xenpvh: Add a basic description Edgar E. Iglesias
2024-08-13  1:49   ` Stefano Stabellini

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=ZrzMkI5jGUtXU2qA@zapote \
    --to=edgar.iglesias@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=anthony@xenproject.org \
    --cc=edgar.iglesias@amd.com \
    --cc=jason.andryuk@amd.com \
    --cc=paul@xen.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xenia.ragiadakou@amd.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).