All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs
Date: Tue, 4 Apr 2017 12:43:37 +0100	[thread overview]
Message-ID: <f97377f1-30a6-020e-ee8d-79c6ced455b0@arm.com> (raw)
In-Reply-To: <20170403202829.7278-10-andre.przywara@arm.com>

Hi Andre,

On 03/04/17 21:28, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. We only care about mapped LPIs, so we can get away
> with having struct pending_irq's only for them.
> Maintain a radix tree per domain where we drop the pointer to the
> respective pending_irq. The index used is the virtual LPI number.
> The memory for the actual structures has been allocated already per
> device at device mapping time.
> Teach the existing VGIC functions to find the right pointer when being
> given a virtual LPI number.
> We also take care of checking for a NULL pointer in the VCPU exit path,
> should an LPI have been removed from the tree for any reason.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic.c           | 12 ++++++++++++
>  xen/arch/arm/vgic-v3.c       | 21 +++++++++++++++++++++
>  xen/arch/arm/vgic.c          |  5 +++++
>  xen/include/asm-arm/domain.h |  2 ++
>  xen/include/asm-arm/vgic.h   |  1 +
>  5 files changed, 41 insertions(+)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 9522c6c..3ed6f81 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -461,7 +461,19 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>
>      gic_hw_ops->read_lr(i, &lr_val);
>      irq = lr_val.virq;
> +

Spurious change.

>      p = irq_to_pending(v, irq);
> +    /* An LPI might have been unmapped, in which case we just clean up here. */
> +    if ( !p )

I cannot find any code removing a pending_irq from the radix tree, so it 
is hard to know how p will not be freed whilst in use here. Is there any 
lock?

> +    {
> +        ASSERT(is_lpi(irq));
> +
> +        gic_hw_ops->clear_lr(i);
> +        clear_bit(i, &this_cpu(lr_mask));
> +
> +        return;
> +    }
> +
>      if ( lr_val.state & GICH_LR_ACTIVE )
>      {
>          set_bit(GIC_IRQ_GUEST_ACTIVE, &p->status);
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 3c7161b..95fa0ba 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -330,6 +330,23 @@ read_unknown:
>      return 1;
>  }
>
> +/*
> + * Looks up a virtual LPI number in our tree of mapped LPIs. This will return
> + * the corresponding struct pending_irq, which we also use to store the
> + * enabled and pending bit plus the priority.
> + * Returns NULL if an LPI cannot be found.

See my question above regarding the behavior of this function. It is not 
clear to me what is protecting the pending_irq to be freed whilst in use.

> + */
> +struct pending_irq *lpi_to_pending(struct domain *d, unsigned int lpi)

This function ought to be a vgic_ops callback. I will not say it again.

> +{
> +    struct pending_irq *pirq;
> +
> +    read_lock(&d->arch.vgic.pend_lpi_tree_lock);
> +    pirq = radix_tree_lookup(&d->arch.vgic.pend_lpi_tree, lpi);
> +    read_unlock(&d->arch.vgic.pend_lpi_tree_lock);
> +
> +    return pirq;
> +}
> +
>  static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>                                            uint32_t gicr_reg,
>                                            register_t r)
> @@ -1452,6 +1469,9 @@ static int vgic_v3_domain_init(struct domain *d)
>      spin_lock_init(&d->arch.vgic.its_devices_lock);
>      d->arch.vgic.its_devices = RB_ROOT;
>
> +    rwlock_init(&d->arch.vgic.pend_lpi_tree_lock);
> +    radix_tree_init(&d->arch.vgic.pend_lpi_tree);
> +
>      /*
>       * Domain 0 gets the hardware address.
>       * Guests get the virtual platform layout.
> @@ -1525,6 +1545,7 @@ static int vgic_v3_domain_init(struct domain *d)
>  static void vgic_v3_domain_free(struct domain *d)
>  {
>      gicv3_its_unmap_all_devices(d);
> +    radix_tree_destroy(&d->arch.vgic.pend_lpi_tree, NULL);

You may have thousands LPIs mapped, how long will you expect this to take?

>      xfree(d->arch.vgic.rdist_regions);
>  }
>
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 67d75a6..28f6f66 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -431,10 +431,15 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode,
>  struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>  {
>      struct pending_irq *n;
> +

Spurious change.

>      /* Pending irqs allocation strategy: the first vgic.nr_spis irqs
>       * are used for SPIs; the rests are used for per cpu irqs */
>      if ( irq < 32 )
>          n = &v->arch.vgic.pending_irqs[irq];
> +#ifdef CONFIG_HAS_ITS

I really don't want to see #ifdef CONFIG_HAS_ITS nor vGIC specific 
function called directly from the common code. Please introduce proper 
vgic_ops.

> +    else if ( is_lpi(irq) )
> +        n = lpi_to_pending(v->domain, irq);
> +#endif
>      else
>          n = &v->domain->arch.vgic.pending_irqs[irq - 32];
>      return n;
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 503a3cf..6ee7538 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -111,6 +111,8 @@ struct arch_domain
>          uint32_t rdist_stride;              /* Re-Distributor stride */
>          struct rb_root its_devices;         /* Devices mapped to an ITS */
>          spinlock_t its_devices_lock;        /* Protects the its_devices tree */
> +        struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
> +        rwlock_t pend_lpi_tree_lock;        /* Protects the pend_lpi_tree */
>  #endif
>      } vgic;
>
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 894c3f1..69ef160 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -300,6 +300,7 @@ extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
>  extern void vgic_clear_pending_irqs(struct vcpu *v);
>  extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
>  extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq);
> +extern struct pending_irq *lpi_to_pending(struct domain *d, unsigned int irq);
>  extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n, int s);
>  extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq);
>  extern bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-04-04 11:43 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-03 20:28 [PATCH v4 00/27] arm64: Dom0 ITS emulation Andre Przywara
2017-04-03 20:28 ` [PATCH v4 01/27] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT Andre Przywara
2017-04-05  0:40   ` Stefano Stabellini
2017-04-03 20:28 ` [PATCH v4 02/27] ARM: GICv3 ITS: initialize host ITS Andre Przywara
2017-04-03 21:03   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 03/27] ARM: GICv3: allocate LPI pending and property table Andre Przywara
2017-04-03 21:47   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 04/27] ARM: GICv3 ITS: allocate device and collection table Andre Przywara
2017-04-05  0:56   ` Stefano Stabellini
2017-04-03 20:28 ` [PATCH v4 05/27] ARM: GICv3 ITS: map ITS command buffer Andre Przywara
2017-04-03 21:56   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 06/27] ARM: GICv3 ITS: introduce ITS command handling Andre Przywara
2017-04-03 22:39   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 07/27] ARM: GICv3 ITS: introduce host LPI array Andre Przywara
2017-04-03 23:07   ` Julien Grall
2017-04-04 10:40     ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 08/27] ARM: GICv3 ITS: introduce device mapping Andre Przywara
2017-04-04  9:03   ` Julien Grall
2017-04-04 16:13   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs Andre Przywara
2017-04-04 11:43   ` Julien Grall [this message]
2017-04-03 20:28 ` [PATCH v4 10/27] ARM: GICv3: forward pending LPIs to guests Andre Przywara
2017-04-04 11:55   ` Julien Grall
2017-04-04 15:36   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 11/27] ARM: GICv3: enable ITS and LPIs on the host Andre Przywara
2017-04-03 20:28 ` [PATCH v4 12/27] ARM: vGICv3: handle virtual LPI pending and property tables Andre Przywara
2017-04-04 13:01   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 13/27] ARM: vGICv3: Handle disabled LPIs Andre Przywara
2017-04-03 20:28 ` [PATCH v4 14/27] ARM: vGICv3: introduce basic ITS emulation bits Andre Przywara
2017-04-04 13:35   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 15/27] ARM: vITS: introduce translation table walks Andre Przywara
2017-04-04 15:59   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 16/27] ARM: vITS: handle CLEAR command Andre Przywara
2017-04-04 16:03   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 17/27] ARM: vITS: handle INT command Andre Przywara
2017-04-04 16:05   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 18/27] ARM: vITS: handle MAPC command Andre Przywara
2017-04-04 16:08   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 19/27] ARM: vITS: handle MAPD command Andre Przywara
2017-04-04 16:09   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 20/27] ARM: vITS: handle MAPTI command Andre Przywara
2017-04-04 16:22   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 21/27] ARM: vITS: handle MOVI command Andre Przywara
2017-04-04 16:37   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 22/27] ARM: vITS: handle DISCARD command Andre Przywara
2017-04-04 16:40   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 23/27] ARM: vITS: handle INV command Andre Przywara
2017-04-04 16:51   ` Julien Grall
2017-04-05 23:21     ` André Przywara
2017-04-03 20:28 ` [PATCH v4 24/27] ARM: vITS: handle INVALL command Andre Przywara
2017-04-04 17:00   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 25/27] ARM: vITS: create and initialize virtual ITSes for Dom0 Andre Przywara
2017-04-04 17:03   ` Julien Grall
2017-04-03 20:28 ` [PATCH v4 26/27] ARM: vITS: create ITS subnodes for Dom0 DT Andre Przywara
2017-04-03 20:28 ` [PATCH v4 27/27] ARM: vGIC: advertise LPI support Andre Przywara
2017-04-05 13:06   ` Julien Grall
2017-04-04 12:36 ` [PATCH v4 00/27] arm64: Dom0 ITS emulation Julien Grall

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=f97377f1-30a6-020e-ee8d-79c6ced455b0@arm.com \
    --to=julien.grall@arm.com \
    --cc=andre.przywara@arm.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.