All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Rahul Singh <Rahul.Singh@arm.com>
Cc: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
	 "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>,
	 "julien@xen.org" <julien@xen.org>,
	 Stefano Stabellini <sstabellini@kernel.org>,
	 Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>,
	 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	 Artem Mygaiev <Artem_Mygaiev@epam.com>,
	 "roger.pau@citrix.com" <roger.pau@citrix.com>,
	 Bertrand Marquis <Bertrand.Marquis@arm.com>,
	 Oleksandr Andrushchenko <andr2000@gmail.com>
Subject: Re: [PATCH 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain
Date: Wed, 15 Sep 2021 13:33:29 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2109151321030.21985@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <6EA9A8EE-8101-4679-832C-A912819891BC@arm.com>

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

On Wed, 15 Sep 2021, Rahul Singh wrote:
> Hi Oleksandr, Stefano,
> 
> > On 15 Sep 2021, at 6:30 am, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com> wrote:
> > 
> > Hi, Rahul!
> > 
> > On 14.09.21 17:24, Oleksandr Andrushchenko wrote:
> >> 
> >> }
> >>>>   +static int pci_ecam_register_mmio_handler(struct domain *d,
> >>>> +                                          struct pci_host_bridge *bridge,
> >>>> +                                          const struct mmio_handler_ops *ops)
> >>>> +{
> >>>> +    struct pci_config_window *cfg = bridge->sysdata;
> >>>> +
> >>>> +    register_mmio_handler(d, ops, cfg->phys_addr, cfg->size, NULL);
> >>>> +    return 0;
> >>>> +}
> >>> Given that struct pci_config_window is generic (it is not specific to
> >>> one bridge), I wonder if we even need the .register_mmio_handler
> >>> callback here.
> >>> 
> >>> In fact,pci_host_bridge->sysdata doesn't even need to be a void*, it
> >>> could be a struct pci_config_window*, right?
> >> 
> >> Rahul, this actually may change your series.
> >> 
> >> Do you think we can do that?
> >> 
> > This is the only change requested that left unanswered by now.
> > 
> > Will it be possible that you change the API accordingly, so I can
> > 
> > implement as Stefano suggests?
> 
> We need pci_host_bridge->sysdata as void* in case we need to implement the new non-ecam PCI controller in XEN.
> Please have a look once in Linux code[1] how bridge->sysdata will be used. struct pci_config_window is used only for 
> ecam supported host controller. Different PCI host controller will have different PCI interface to access the PCI controller.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pcie-rcar-host.c#n309
> 
> I think we need bridge->sysdata in future to implement the new PCI controller.

In my opinion the pci_config_window is too important of an information
to be left inside an opaque pointer, especially when the info under
pci_config_window is both critical and vendor-neutral.

My preference would be something like this:


diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index 9c28a4bdc4..c80d846da3 100644
--- a/xen/include/asm-arm/pci.h
+++ b/xen/include/asm-arm/pci.h
@@ -55,7 +55,6 @@ struct pci_config_window {
     uint8_t         busn_start;
     uint8_t         busn_end;
     void __iomem    *win;
-    const struct    pci_ecam_ops *ops;
 };
 
 /*
@@ -68,7 +67,8 @@ struct pci_host_bridge {
     uint16_t segment;                /* Segment number */
     u8 bus_start;                    /* Bus start of this bridge. */
     u8 bus_end;                      /* Bus end of this bridge. */
-    void *sysdata;                   /* Pointer to the config space window*/
+    struct pci_config_window* cfg;   /* Pointer to the bridge config window */
+    void *sysdata;                   /* Pointer to bridge private data */
     const struct pci_ops *ops;
 };


As a reference the attached patch builds. However, I had to remove const
where struct pci_ecam_ops *ops is used.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=cfg.patch, Size: 4990 bytes --]

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ecfa6822e4..f9d57ca0fa 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -7,6 +7,7 @@ config ARM_64
 	depends on !ARM_32
 	select 64BIT
 	select HAS_FAST_MULTIPLY
+	select HAS_PCI
 
 config ARM
 	def_bool y
diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
index d32efb7fcb..f6d0d00c1b 100644
--- a/xen/arch/arm/pci/ecam.c
+++ b/xen/arch/arm/pci/ecam.c
@@ -26,8 +26,9 @@
 void __iomem *pci_ecam_map_bus(struct pci_host_bridge *bridge,
                                       uint32_t sbdf, uint32_t where)
 {
-    const struct pci_config_window *cfg = bridge->sysdata;
-    unsigned int devfn_shift = cfg->ops->bus_shift - 8;
+    const struct pci_ecam_ops *ops = bridge->sysdata;
+    const struct pci_config_window *cfg = bridge->cfg;
+    unsigned int devfn_shift = ops->bus_shift - 8;
     void __iomem *base;
 
     pci_sbdf_t sbdf_t = (pci_sbdf_t) sbdf ;
@@ -37,7 +38,7 @@ void __iomem *pci_ecam_map_bus(struct pci_host_bridge *bridge,
         return NULL;
 
     busn -= cfg->busn_start;
-    base = cfg->win + (busn << cfg->ops->bus_shift);
+    base = cfg->win + (busn << ops->bus_shift);
 
     return base + (PCI_DEVFN(sbdf_t.dev, sbdf_t.fn) << devfn_shift) + where;
 }
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host-common.c
index c04be63645..41a5457e80 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -97,7 +97,6 @@ static struct pci_config_window *gen_pci_init(struct dt_device_node *dev,
 
     cfg->phys_addr = addr;
     cfg->size = size;
-    cfg->ops = ops;
 
     /*
      * On 64-bit systems, we do a single ioremap for the whole config space
@@ -225,7 +224,7 @@ static int pci_bus_find_domain_nr(struct dt_device_node *dev)
 }
 
 int pci_host_common_probe(struct dt_device_node *dev,
-                          const struct pci_ecam_ops *ops,
+                          struct pci_ecam_ops *ops,
                           int ecam_reg_idx)
 {
     struct pci_host_bridge *bridge;
@@ -245,7 +244,8 @@ int pci_host_common_probe(struct dt_device_node *dev,
     }
 
     bridge->dt_node = dev;
-    bridge->sysdata = cfg;
+    bridge->cfg = cfg;
+    bridge->sysdata = ops;
     bridge->ops = &ops->pci_ops;
     bridge->bus_start = cfg->busn_start;
     bridge->bus_end = cfg->busn_end;
diff --git a/xen/arch/arm/pci/pci-host-generic.c b/xen/arch/arm/pci/pci-host-generic.c
index 2d652e8910..66176f9658 100644
--- a/xen/arch/arm/pci/pci-host-generic.c
+++ b/xen/arch/arm/pci/pci-host-generic.c
@@ -32,7 +32,7 @@ static const struct dt_device_match gen_pci_dt_match[] = {
 static int gen_pci_dt_init(struct dt_device_node *dev, const void *data)
 {
     const struct dt_device_match *of_id;
-    const struct pci_ecam_ops *ops;
+    struct pci_ecam_ops *ops;
 
     of_id = dt_match_node(gen_pci_dt_match, dev->dev.of_node);
     ops = (struct pci_ecam_ops *) of_id->data;
diff --git a/xen/arch/arm/pci/pci-host-zynqmp.c b/xen/arch/arm/pci/pci-host-zynqmp.c
index fe103e3855..b4170c3bdd 100644
--- a/xen/arch/arm/pci/pci-host-zynqmp.c
+++ b/xen/arch/arm/pci/pci-host-zynqmp.c
@@ -32,7 +32,7 @@ static const struct dt_device_match gen_pci_dt_match[] = {
 static int gen_pci_dt_init(struct dt_device_node *dev, const void *data)
 {
     const struct dt_device_match *of_id;
-    const struct pci_ecam_ops *ops;
+    struct pci_ecam_ops *ops;
 
     of_id = dt_match_node(gen_pci_dt_match, dev->dev.of_node);
     ops = (struct pci_ecam_ops *) of_id->data;
diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index 9c28a4bdc4..c80d846da3 100644
--- a/xen/include/asm-arm/pci.h
+++ b/xen/include/asm-arm/pci.h
@@ -55,7 +55,6 @@ struct pci_config_window {
     uint8_t         busn_start;
     uint8_t         busn_end;
     void __iomem    *win;
-    const struct    pci_ecam_ops *ops;
 };
 
 /*
@@ -68,7 +67,8 @@ struct pci_host_bridge {
     uint16_t segment;                /* Segment number */
     u8 bus_start;                    /* Bus start of this bridge. */
     u8 bus_end;                      /* Bus end of this bridge. */
-    void *sysdata;                   /* Pointer to the config space window*/
+    struct pci_config_window* cfg;   /* Pointer to the bridge config window */
+    void *sysdata;                   /* Pointer to bridge private data */
     const struct pci_ops *ops;
 };
 
@@ -100,7 +100,7 @@ struct pci_ecam_ops {
 extern const struct pci_ecam_ops pci_generic_ecam_ops;
 
 int pci_host_common_probe(struct dt_device_node *dev,
-                          const struct pci_ecam_ops *ops,
+                          struct pci_ecam_ops *ops,
                           int ecam_reg_idx);
 int pci_generic_config_read(struct pci_host_bridge *bridge, uint32_t sbdf,
                             uint32_t reg, uint32_t len, uint32_t *value);

  parent reply	other threads:[~2021-09-15 20:33 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03  8:33 [PATCH 00/11] PCI devices passthrough on Arm, part 2 Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 01/11] xen/arm: Add new device type for PCI Oleksandr Andrushchenko
2021-09-09 17:19   ` Julien Grall
2021-09-10  7:40     ` Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 02/11] xen/arm: Add dev_to_pci helper Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 03/11] xen/arm: Introduce pci_find_host_bridge_node helper Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 04/11] xen/device-tree: Make dt_find_node_by_phandle global Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 05/11] xen/arm: Mark device as PCI while creating one Oleksandr Andrushchenko
2021-09-03 12:41   ` Jan Beulich
2021-09-03 13:26     ` Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 06/11] xen/domain: Call pci_release_devices() when releasing domain resources Oleksandr Andrushchenko
2021-09-10 18:45   ` Stefano Stabellini
2021-09-03  8:33 ` [PATCH 07/11] libxl: Allow removing PCI devices for all types of domains Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported Oleksandr Andrushchenko
2021-09-03 10:26   ` Juergen Gross
2021-09-03 10:30     ` Oleksandr Andrushchenko
2021-09-10 19:06   ` Stefano Stabellini
2021-09-13  8:22     ` Oleksandr Andrushchenko
2021-09-03  8:33 ` [PATCH 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain Oleksandr Andrushchenko
2021-09-09 17:43   ` Julien Grall
2021-09-10 11:43     ` Oleksandr Andrushchenko
2021-09-10 13:04       ` Julien Grall
2021-09-10 13:15         ` Oleksandr Andrushchenko
2021-09-10 13:20           ` Julien Grall
2021-09-10 13:27             ` Oleksandr Andrushchenko
2021-09-10 13:33               ` Julien Grall
2021-09-10 13:40                 ` Oleksandr Andrushchenko
2021-09-14 13:47                   ` Oleksandr Andrushchenko
2021-09-15  0:25                     ` Stefano Stabellini
2021-09-15  4:50                       ` Oleksandr Andrushchenko
2021-09-10 20:12   ` Stefano Stabellini
2021-09-14 14:24     ` Oleksandr Andrushchenko
2021-09-15  5:30       ` Oleksandr Andrushchenko
2021-09-15 10:45         ` Rahul Singh
2021-09-15 11:55           ` Oleksandr Andrushchenko
2021-09-15 20:33           ` Stefano Stabellini [this message]
2021-09-17  6:13             ` Oleksandr Andrushchenko
2021-09-17  7:29               ` Rahul Singh
2021-09-03  8:33 ` [PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m Oleksandr Andrushchenko
2021-09-09 17:58   ` Julien Grall
2021-09-10 12:37     ` Oleksandr Andrushchenko
2021-09-10 13:18       ` Julien Grall
2021-09-10 14:01         ` Oleksandr Andrushchenko
2021-09-10 14:18           ` Julien Grall
2021-09-10 14:38             ` Oleksandr Andrushchenko
2021-09-10 14:52               ` Julien Grall
2021-09-10 15:01                 ` Oleksandr Andrushchenko
2021-09-10 15:05                   ` Julien Grall
2021-09-10 15:04           ` Julien Grall
2021-09-10 20:30             ` Stefano Stabellini
2021-09-10 21:41               ` Julien Grall
2021-09-13  6:27                 ` Oleksandr Andrushchenko
2021-09-14 10:03                   ` Oleksandr Andrushchenko
2021-09-15  0:36                     ` Stefano Stabellini
2021-09-15  5:35                       ` Oleksandr Andrushchenko
2021-09-15 16:42                         ` Rahul Singh
2021-09-15 20:09                         ` Stefano Stabellini
2021-09-15 20:19                           ` Stefano Stabellini
2021-09-16  7:16                             ` Oleksandr Andrushchenko
2021-09-16 20:22                               ` Stefano Stabellini
2021-09-03  8:33 ` [PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations Oleksandr Andrushchenko
2021-09-03  9:04   ` Julien Grall
2021-09-06  7:02     ` Oleksandr Andrushchenko
2021-09-06  8:48       ` Julien Grall
2021-09-06  9:14         ` Oleksandr Andrushchenko
2021-09-06  9:53           ` Julien Grall
2021-09-06 10:06             ` Oleksandr Andrushchenko
2021-09-06 10:38               ` Julien Grall
2021-09-07  6:34                 ` Oleksandr Andrushchenko

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=alpine.DEB.2.21.2109151321030.21985@sstabellini-ThinkPad-T480s \
    --to=sstabellini@kernel.org \
    --cc=Artem_Mygaiev@epam.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Oleksandr_Andrushchenko@epam.com \
    --cc=Oleksandr_Tyshchenko@epam.com \
    --cc=Rahul.Singh@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andr2000@gmail.com \
    --cc=julien@xen.org \
    --cc=roger.pau@citrix.com \
    --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.