All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vikram Garhwal <vikram.garhwal@amd.com>
To: Michal Orzel <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
	julien@xen.org, Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [XEN][PATCH v10 03/20] xen/arm/device: Remove __init from function type
Date: Wed, 30 Aug 2023 10:16:20 -0700	[thread overview]
Message-ID: <ZO95ZLh9FdpmGMWL@amd.com> (raw)
In-Reply-To: <64099c1c-42d6-aeb4-6d2f-566dc17580da@amd.com>

Hi Michal,
On Tue, Aug 29, 2023 at 09:17:37AM +0200, Michal Orzel wrote:
> 
> 
> On 25/08/2023 10:02, Vikram Garhwal wrote:
> > Remove __init from following function to access during runtime:
> >     1. map_irq_to_domain()
> >     2. handle_device_interrupts()
> >     3. map_range_to_domain()
> >     4. unflatten_dt_node()
> >     5. handle_device()
> >     6. map_device_children()
> >     7. map_dt_irq_to_domain()
> > Move map_irq_to_domain() prototype from domain_build.h to setup.h.
> > 
> > Above changes will create an error on build as non-init function are still
> > in domain_build.c file. So, to avoid build fails, following changes are done:
> > 1. Move map_irq_to_domain(), handle_device_interrupts(), map_range_to_domain(),
> >     handle_device(), map_device_children() and map_dt_irq_to_domain()
> >     to device.c. After removing __init type,  these functions are not specific
> >     to domain building, so moving them out of domain_build.c to device.c.
> > 2. Remove static type from handle_device_interrupts().
> > 
> > Overall, these changes are done to support the dynamic programming of a nodes
> > where an overlay node will be added to fdt and unflattened node will be added to
> > dt_host. Furthermore, IRQ and mmio mapping will be done for the added node.
> > 
> > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> > 
> > ---
> > Changes from v9:
> >     Move handle_device(), map_device_children() and map_dt_irq_to_domain() out
> >         of domain_build.c
> > ---
> > ---
> >  xen/arch/arm/device.c                   | 293 ++++++++++++++++++++++++
> >  xen/arch/arm/domain_build.c             | 293 ------------------------
> >  xen/arch/arm/include/asm/domain_build.h |   2 -
> >  xen/arch/arm/include/asm/setup.h        |   9 +
> >  xen/common/device_tree.c                |  12 +-
> >  5 files changed, 308 insertions(+), 301 deletions(-)
> > 
> > diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
> > index ca8539dee5..857f171a27 100644
> > --- a/xen/arch/arm/device.c
> > +++ b/xen/arch/arm/device.c
> > @@ -9,8 +9,10 @@
> >   */
> >  
> >  #include <asm/device.h>
> > +#include <asm/setup.h>
> >  #include <xen/errno.h>
> >  #include <xen/init.h>
> > +#include <xen/iocap.h>
> >  #include <xen/lib.h>
> >  
> >  extern const struct device_desc _sdevice[], _edevice[];
> > @@ -75,6 +77,297 @@ enum device_class device_get_class(const struct dt_device_node *dev)
> >      return DEVICE_UNKNOWN;
> >  }
> >  
> > +int map_irq_to_domain(struct domain *d, unsigned int irq,
> > +                      bool need_mapping, const char *devname)
> > +{
> > +    int res;
> > +
> > +    res = irq_permit_access(d, irq);
> > +    if ( res )
> > +    {
> > +        printk(XENLOG_ERR "Unable to permit to %pd access to IRQ %u\n", d, irq);
> > +        return res;
> > +    }
> > +
> > +    if ( need_mapping )
> > +    {
> > +        /*
> > +         * Checking the return of vgic_reserve_virq is not
> > +         * necessary. It should not fail except when we try to map
> > +         * the IRQ twice. This can legitimately happen if the IRQ is shared
> > +         */
> > +        vgic_reserve_virq(d, irq);
> > +
> > +        res = route_irq_to_guest(d, irq, irq, devname);
> > +        if ( res < 0 )
> > +        {
> > +            printk(XENLOG_ERR "Unable to map IRQ%u to %pd\n", irq, d);
> > +            return res;
> > +        }
> > +    }
> > +
> > +    dt_dprintk("  - IRQ: %u\n", irq);
> > +    return 0;
> > +}
> > +
> > +int map_range_to_domain(const struct dt_device_node *dev,
> > +                        uint64_t addr, uint64_t len, void *data)
> > +{
> > +    struct map_range_data *mr_data = data;
> > +    struct domain *d = mr_data->d;
> > +    int res;
> > +
> > +    if ( (addr != (paddr_t)addr) || (((paddr_t)~0 - addr) < len) )
> > +    {
> > +        printk(XENLOG_ERR "%s: [0x%"PRIx64", 0x%"PRIx64"] exceeds the maximum allowed PA width (%u bits)",
> > +               dt_node_full_name(dev), addr, (addr + len), PADDR_BITS);
> > +        return -ERANGE;
> > +    }
> > +
> > +    /*
> > +     * reserved-memory regions are RAM carved out for a special purpose.
> > +     * They are not MMIO and therefore a domain should not be able to
> > +     * manage them via the IOMEM interface.
> > +     */
> > +    if ( strncasecmp(dt_node_full_name(dev), "/reserved-memory/",
> > +                     strlen("/reserved-memory/")) != 0 )
> > +    {
> > +        res = iomem_permit_access(d, paddr_to_pfn(addr),
> > +                paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
> > +        if ( res )
> > +        {
> > +            printk(XENLOG_ERR "Unable to permit to dom%d access to"
> > +                    " 0x%"PRIx64" - 0x%"PRIx64"\n",
> > +                    d->domain_id,
> > +                    addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
> > +            return res;
> > +        }
> > +    }
> > +
> > +    if ( !mr_data->skip_mapping )
> > +    {
> > +        res = map_regions_p2mt(d,
> > +                               gaddr_to_gfn(addr),
> > +                               PFN_UP(len),
> > +                               maddr_to_mfn(addr),
> > +                               mr_data->p2mt);
> > +
> > +        if ( res < 0 )
> > +        {
> > +            printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> > +                   " - 0x%"PRIx64" in domain %d\n",
> > +                   addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1,
> > +                   d->domain_id);
> > +            return res;
> > +        }
> > +    }
> > +
> > +    dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64" P2MType=%x\n",
> > +               addr, addr + len, mr_data->p2mt);
> > +
> > +    return 0;
> > +}
> > +
> > +/*
> > + * handle_device_interrupts retrieves the interrupts configuration from
> > + * a device tree node and maps those interrupts to the target domain.
> > + *
> > + * Returns:
> > + *   < 0 error
> > + *   0   success
> > + */
> > +int handle_device_interrupts(struct domain *d,
> This needs to be renamed. AFAIK you agreed on map_device_irqs_to_domain().
Yeah, i changed this in v11.
> 
> > +                             struct dt_device_node *dev,
> > +                             bool need_mapping)
> > +{
> > +    unsigned int i, nirq;
> > +    int res;
> > +    struct dt_raw_irq rirq;
> > +
> > +    nirq = dt_number_of_irq(dev);
> > +
> > +    /* Give permission and map IRQs */
> > +    for ( i = 0; i < nirq; i++ )
> > +    {
> > +        res = dt_device_get_raw_irq(dev, i, &rirq);
> > +        if ( res )
> > +        {
> > +            printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n",
> > +                   i, dt_node_full_name(dev));
> > +            return res;
> > +        }
> > +
> > +        /*
> > +         * Don't map IRQ that have no physical meaning
> > +         * ie: IRQ whose controller is not the GIC
> > +         */
> > +        if ( rirq.controller != dt_interrupt_controller )
> > +        {
> > +            dt_dprintk("irq %u not connected to primary controller. Connected to %s\n",
> > +                      i, dt_node_full_name(rirq.controller));
> > +            continue;
> > +        }
> > +
> > +        res = platform_get_irq(dev, i);
> > +        if ( res < 0 )
> > +        {
> > +            printk(XENLOG_ERR "Unable to get irq %u for %s\n",
> > +                   i, dt_node_full_name(dev));
> > +            return res;
> > +        }
> > +
> > +        res = map_irq_to_domain(d, res, need_mapping, dt_node_name(dev));
> > +        if ( res )
> > +            return res;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> > +static int map_dt_irq_to_domain(const struct dt_device_node *dev,
> > +                                       const struct dt_irq *dt_irq,
> > +                                       void *data)
> Parameters are not alligned. Should be:
> static int map_dt_irq_to_domain(const struct dt_device_node *dev,
>                                 const struct dt_irq *dt_irq,
>                                 void *data)
> 
> > +{
> > +    struct map_range_data *mr_data = data;
> > +    struct domain *d = mr_data->d;
> > +    unsigned int irq = dt_irq->irq;
> > +    int res;
> > +
> > +    if ( irq < NR_LOCAL_IRQS )
> > +    {
> > +        printk(XENLOG_ERR "%s: IRQ%u is not a SPI\n", dt_node_name(dev), irq);
> > +        return -EINVAL;
> > +    }
> > +
> > +    /* Setup the IRQ type */
> > +    res = irq_set_spi_type(irq, dt_irq->type);
> > +    if ( res )
> > +    {
> > +        printk(XENLOG_ERR "%s: Unable to setup IRQ%u to %pd\n",
> > +               dt_node_name(dev), irq, d);
> > +        return res;
> > +    }
> > +
> > +    res = map_irq_to_domain(d, irq, !mr_data->skip_mapping, dt_node_name(dev));
> > +
> > +    return res;
> > +}
> > +
> > +/*
> > + * For a node which describes a discoverable bus (such as a PCI bus)
> > + * then we may need to perform additional mappings in order to make
> > + * the child resources available to domain 0.
> > + */
> > +static int map_device_children(const struct dt_device_node *dev,
> > +                                      struct map_range_data *mr_data)
> Parameter is not aligned.
Fixed the style here.
> 
> [...]
> > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> > index 19dc637d55..1a052ed924 100644
> > --- a/xen/arch/arm/include/asm/setup.h
> > +++ b/xen/arch/arm/include/asm/setup.h
> > @@ -165,9 +165,18 @@ void device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
> >  u32 device_tree_get_u32(const void *fdt, int node,
> >                          const char *prop_name, u32 dflt);
> >  
> > +int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
> > +                  struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
> Remove the rangeset parameters. AFAIK you'll introduce it later, so this is a mistake
> causing the build to fail.
Fixed this.
> 
> > +
> > +int handle_device_interrupts(struct domain *d, struct dt_device_node *dev,
> > +                             bool need_mapping);
> Don't forget to rename.
> 
> 
> With all the remarks above addressed:
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> 
> ~Michal
> 


  reply	other threads:[~2023-08-30 17:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25  8:02 [XEN][PATCH v10 00/20] dynamic node programming using overlay dtbo Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 01/20] common/device_tree: handle memory allocation failure in __unflatten_device_tree() Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 02/20] common/device_tree.c: unflatten_device_tree() propagate errors Vikram Garhwal
2023-08-28  1:41   ` Henry Wang
2023-08-29  7:09   ` Michal Orzel
2023-08-29 22:24   ` Stefano Stabellini
2023-08-25  8:02 ` [XEN][PATCH v10 03/20] xen/arm/device: Remove __init from function type Vikram Garhwal
2023-08-28  1:53   ` Henry Wang
2023-08-28 16:21     ` Vikram Garhwal
2023-08-29  7:17   ` Michal Orzel
2023-08-30 17:16     ` Vikram Garhwal [this message]
2023-08-25  8:02 ` [XEN][PATCH v10 04/20] common/device_tree: Export __unflatten_device_tree() Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 05/20] xen/arm: Add CONFIG_OVERLAY_DTB Vikram Garhwal
2023-08-29  7:23   ` Michal Orzel
2023-08-30 17:16     ` Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 06/20] libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 07/20] libfdt: overlay: change overlay_get_target() Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 08/20] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree Vikram Garhwal
2023-08-28  1:59   ` Henry Wang
2023-08-29  7:41   ` Michal Orzel
2023-08-29 22:27   ` Stefano Stabellini
2023-08-25  8:02 ` [XEN][PATCH v10 09/20] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller Vikram Garhwal
2023-08-29  8:05   ` Michal Orzel
2023-08-30 17:20     ` Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 10/20] xen/iommu: protect iommu_add_dt_device() with dtdevs_lock Vikram Garhwal
2023-08-28 16:29   ` Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 11/20] xen/iommu: Introduce iommu_remove_dt_device() Vikram Garhwal
2023-08-29  8:23   ` Michal Orzel
2023-08-30 17:48     ` Vikram Garhwal
2023-08-31  0:35       ` Stefano Stabellini
2023-08-31  7:23       ` Michal Orzel
2023-08-31  7:32         ` Michal Orzel
2023-09-01  2:01           ` Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 12/20] xen/smmu: Add remove_device callback for smmu_iommu ops Vikram Garhwal
2023-08-29  8:51   ` Michal Orzel
2023-08-29 22:45     ` Stefano Stabellini
2023-08-30  9:17       ` Michal Orzel
2023-08-25  8:02 ` [XEN][PATCH v10 13/20] asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 14/20] common/device_tree: Add rwlock for dt_host Vikram Garhwal
2023-08-28 16:26   ` Vikram Garhwal
2023-08-29  9:27   ` Michal Orzel
2023-08-25  8:02 ` [XEN][PATCH v10 15/20] arm/asm/setup.h: Update struct map_range_data to add rangeset Vikram Garhwal
2023-08-29 12:16   ` Michal Orzel
2023-08-25  8:02 ` [XEN][PATCH v10 16/20] xen/arm: Implement device tree node removal functionalities Vikram Garhwal
2023-08-29 23:45   ` Stefano Stabellini
2023-08-25  8:02 ` [XEN][PATCH v10 17/20] xen/arm: Implement device tree node addition functionalities Vikram Garhwal
2023-08-29 23:45   ` Stefano Stabellini
2023-08-25  8:02 ` [XEN][PATCH v10 18/20] tools/libs/ctrl: Implement new xc interfaces for dt overlay Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 19/20] tools/libs/light: Implement new libxl functions for device tree overlay ops Vikram Garhwal
2023-08-25  8:02 ` [XEN][PATCH v10 20/20] tools/xl: Add new xl command overlay for device tree overlay support Vikram Garhwal

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=ZO95ZLh9FdpmGMWL@amd.com \
    --to=vikram.garhwal@amd.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --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.