xen-devel.lists.xenproject.org archive mirror
 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,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Shanker Donthineni <shankerd@codeaurora.org>
Subject: Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock
Date: Tue, 30 May 2017 12:08:50 +0100	[thread overview]
Message-ID: <f038088c-fc74-0883-9abe-2fd57d1d83b5@arm.com> (raw)
In-Reply-To: <20170526173540.10066-4-andre.przywara@arm.com>

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> So far irq_to_pending() is just a convenience function to lookup
> statically allocated arrays. This will change with LPIs, which are
> more dynamic, so the memory for their struct pending_irq might go away.
> The proper answer to the issue of preventing stale pointers is
> ref-counting, which requires more rework and will be introduced with
> a later rework.
> For now move the irq_to_pending() calls that are used with LPIs under the
> VGIC VCPU lock, and only use the returned pointer while holding the lock.
> This prevents the memory from being freed while we use it.
> For the sake of completeness we take care about all irq_to_pending()
> users, even those which later will never deal with LPIs.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic.c  |  5 ++++-
>  xen/arch/arm/vgic.c | 39 ++++++++++++++++++++++++++++++---------
>  2 files changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index da19130..dcb1783 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq *n)
>
>  void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
>  {
> -    struct pending_irq *p = irq_to_pending(v, virtual_irq);
> +    struct pending_irq *p;
>      unsigned long flags;
>
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> +
> +    p = irq_to_pending(v, virtual_irq);
> +
>      if ( !list_empty(&p->lr_queue) )
>          list_del_init(&p->lr_queue);
>      spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 54b2aad..69d732b 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -234,23 +234,29 @@ static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
>  {
>      unsigned long flags;
> -    struct pending_irq *p = irq_to_pending(old, irq);
> +    struct pending_irq *p;
> +
> +    spin_lock_irqsave(&old->arch.vgic.lock, flags);
> +
> +    p = irq_to_pending(old, irq);
>
>      /* nothing to do for virtual interrupts */
>      if ( p->desc == NULL )
> +    {
> +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>          return true;
> +    }
>
>      /* migration already in progress, no need to do anything */
>      if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
>      {
>          gprintk(XENLOG_WARNING, "irq %u migration failed: requested while in progress\n", irq);
> +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>          return false;
>      }
>
>      perfc_incr(vgic_irq_migrates);
>
> -    spin_lock_irqsave(&old->arch.vgic.lock, flags);
> -
>      if ( list_empty(&p->inflight) )
>      {
>          irq_set_affinity(p->desc, cpumask_of(new->processor));
> @@ -285,6 +291,13 @@ void arch_move_irqs(struct vcpu *v)
>      struct vcpu *v_target;
>      int i;
>
> +    /*
> +     * We don't migrate LPIs at the moment.
> +     * If we ever do, we must make sure that the struct pending_irq does
> +     * not go away, as there is no lock preventing this here.
> +     */
> +    ASSERT(!is_lpi(vgic_num_irqs(d) - 1));

Hmmm? This raise a question of why vgic_num_irqs does not include the 
LPIs today...

> +
>      for ( i = 32; i < vgic_num_irqs(d); i++ )
>      {
>          v_target = vgic_get_target_vcpu(v, i);
> @@ -299,6 +312,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>  {
>      const unsigned long mask = r;
>      struct pending_irq *p;
> +    struct irq_desc *desc;
>      unsigned int irq;
>      unsigned long flags;
>      int i = 0;
> @@ -307,14 +321,19 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>          irq = i + (32 * n);
>          v_target = vgic_get_target_vcpu(v, irq);
> +
> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          p = irq_to_pending(v_target, irq);
>          clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>          gic_remove_from_queues(v_target, irq);

gic_remove_from_queues is taking v_target vGIC lock. So you just 
introduced a deadlock. You remove it in the next patch but still, we 
should not introduce regression even temporarily. This would make to 
difficult to bisect the series.

TBH, I am not a big fan of spreading the mess of vGIC locking when we 
are going to rework the vGIC and know that this code will not be called 
for LPIs.

BTW, this series is not bisectable because the host ITS is only enabled 
from patch #12.

> -        if ( p->desc != NULL )
> +        desc = p->desc;
> +        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> +
> +        if ( desc != NULL )
>          {
> -            spin_lock_irqsave(&p->desc->lock, flags);
> -            p->desc->handler->disable(p->desc);
> -            spin_unlock_irqrestore(&p->desc->lock, flags);
> +            spin_lock_irqsave(&desc->lock, flags);
> +            desc->handler->disable(desc);
> +            spin_unlock_irqrestore(&desc->lock, flags);
>          }
>          i++;
>      }
> @@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>          irq = i + (32 * n);
>          v_target = vgic_get_target_vcpu(v, irq);
> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          p = irq_to_pending(v_target, irq);
>          set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> -        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          if ( !list_empty(&p->inflight) && !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
>              gic_raise_guest_irq(v_target, irq, p->priority);
>          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> @@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>  {
>      uint8_t priority;
> -    struct pending_irq *iter, *n = irq_to_pending(v, virq);
> +    struct pending_irq *iter, *n;
>      unsigned long flags;
>      bool running;
>
> @@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
> +    n = irq_to_pending(v, virq);
> +
>      /* vcpu offline */
>      if ( test_bit(_VPF_down, &v->pause_flags) )
>      {
>

Cheers,

-- 
Julien Grall

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

  reply	other threads:[~2017-05-30 11:08 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 17:35 [PATCH v10 00/32] arm64: Dom0 ITS emulation Andre Przywara
2017-05-26 17:35 ` [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority Andre Przywara
2017-05-30 10:47   ` Julien Grall
2017-05-30 21:39     ` Stefano Stabellini
2017-05-31 10:42       ` Julien Grall
2017-06-02 17:44         ` Julien Grall
2017-06-06 17:06     ` Andre Przywara
2017-06-06 17:11       ` Julien Grall
2017-06-06 17:20         ` Andre Przywara
2017-06-06 17:21           ` Julien Grall
2017-06-06 18:39             ` Stefano Stabellini
2017-05-26 17:35 ` [PATCH v10 02/32] ARM: GICv3: setup number of LPI bits for a GICv3 guest Andre Przywara
2017-05-30 10:54   ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock Andre Przywara
2017-05-30 11:08   ` Julien Grall [this message]
2017-05-30 21:46     ` Stefano Stabellini
2017-05-31 10:44       ` Julien Grall
2017-06-06 17:24     ` Andre Przywara
2017-06-06 18:46       ` Stefano Stabellini
2017-06-07 10:49         ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 04/32] ARM: vGIC: rework gic_remove_from_queues() Andre Przywara
2017-05-30 11:15   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 05/32] ARM: vGIC: introduce gic_remove_irq() Andre Przywara
2017-05-30 11:31   ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's Andre Przywara
2017-05-30 11:38   ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-06-07 11:19       ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 07/32] ARM: GICv3: introduce separate pending_irq structs for LPIs Andre Przywara
2017-05-26 17:35 ` [PATCH v10 08/32] ARM: GIC: export and extend vgic_init_pending_irq() Andre Przywara
2017-05-26 17:35 ` [PATCH v10 09/32] ARM: vGIC: cache virtual LPI priority in struct pending_irq Andre Przywara
2017-05-26 17:35 ` [PATCH v10 10/32] ARM: vGIC: add LPI VCPU ID to " Andre Przywara
2017-05-26 17:35 ` [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests Andre Przywara
2017-05-30 11:56   ` Julien Grall
2017-05-30 22:07     ` Stefano Stabellini
2017-05-31 11:09       ` Julien Grall
2017-05-31 17:56         ` Stefano Stabellini
2017-05-31 18:39           ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 12/32] ARM: GICv3: enable ITS and LPIs on the host Andre Przywara
2017-05-30 11:58   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 13/32] ARM: vGICv3: handle virtual LPI pending and property tables Andre Przywara
2017-05-26 17:35 ` [PATCH v10 14/32] ARM: introduce vgic_access_guest_memory() Andre Przywara
2017-05-26 17:35 ` [PATCH v10 15/32] ARM: vGICv3: re-use vgic_reg64_check_access Andre Przywara
2017-05-26 17:35 ` [PATCH v10 16/32] ARM: vGIC: advertise LPI support Andre Przywara
2017-05-30 12:59   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation Andre Przywara
2017-06-01 18:13   ` Julien Grall
2017-06-08  9:57   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 18/32] ARM: vITS: introduce translation table walks Andre Przywara
2017-06-02 16:25   ` Julien Grall
2017-06-08  9:35   ` Julien Grall
2017-06-08  9:45     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq Andre Przywara
2017-06-02 16:32   ` Julien Grall
2017-06-02 16:45     ` Julien Grall
2017-06-06 10:19     ` Andre Przywara
2017-06-06 11:13       ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 20/32] ARM: vITS: handle INT command Andre Przywara
2017-06-02 16:37   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 21/32] ARM: vITS: handle MAPC command Andre Przywara
2017-05-26 17:35 ` [PATCH v10 22/32] ARM: vITS: handle CLEAR command Andre Przywara
2017-06-02 16:40   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 23/32] ARM: vITS: handle MAPD command Andre Przywara
2017-06-02 16:46   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs Andre Przywara
2017-06-02 16:55   ` Julien Grall
2017-06-02 20:45     ` Stefano Stabellini
2017-06-08  9:45   ` Julien Grall
2017-06-08 13:51     ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command Andre Przywara
2017-06-02 17:12   ` Julien Grall
2017-06-07 17:49     ` Andre Przywara
2017-06-12 16:33       ` Julien Grall
2017-06-09 11:17     ` Andre Przywara
2017-06-09 19:14       ` Stefano Stabellini
2017-06-12 16:10         ` Andre Przywara
2017-05-26 17:35 ` [PATCH v10 26/32] ARM: vITS: handle MOVI command Andre Przywara
2017-05-30 22:35   ` Stefano Stabellini
2017-05-31 11:23     ` Julien Grall
2017-05-31 17:53       ` Stefano Stabellini
2017-05-31 18:49         ` Julien Grall
2017-06-02 17:17           ` Julien Grall
2017-06-02 20:36             ` Stefano Stabellini
2017-05-26 17:35 ` [PATCH v10 27/32] ARM: vITS: handle DISCARD command Andre Przywara
2017-06-02 17:21   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 28/32] ARM: vITS: handle INV command Andre Przywara
2017-05-30 22:23   ` Stefano Stabellini
2017-05-26 17:35 ` [PATCH v10 29/32] ARM: vITS: handle INVALL command Andre Przywara
2017-06-02 17:27   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 30/32] ARM: vITS: increase mmio_count for each ITS Andre Przywara
2017-05-26 17:35 ` [PATCH v10 31/32] ARM: vITS: create and initialize virtual ITSes for Dom0 Andre Przywara
2017-06-02 17:31   ` Julien Grall
2017-05-26 17:35 ` [PATCH v10 32/32] ARM: vITS: create ITS subnodes for Dom0 DT Andre Przywara
2017-06-02 17:33   ` 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=f038088c-fc74-0883-9abe-2fd57d1d83b5@arm.com \
    --to=julien.grall@arm.com \
    --cc=Vijaya.Kumar@caviumnetworks.com \
    --cc=andre.przywara@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=vijay.kilari@gmail.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 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).