xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@linaro.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, Julien Grall <julien.grall@linaro.org>
Subject: Re: [PATCH 03/12] ARM: VGIC: remove gic_clear_pending_irqs()
Date: Wed, 6 Dec 2017 18:01:18 +0000	[thread overview]
Message-ID: <a7f85279-9dc0-3304-a8b8-547f851b2581@linaro.org> (raw)
In-Reply-To: <73633804-76ff-aacc-d71d-ec9deb67be9d@linaro.org>

Hi,

On 10/11/17 16:42, Andre Przywara wrote:
> Hi,
> 
> On 26/10/17 01:14, Stefano Stabellini wrote:
>> On Thu, 19 Oct 2017, Andre Przywara wrote:
>>> gic_clear_pending_irqs() was not only misnamed, but also misplaced, as
>>> a function solely dealing with the GIC emulation should not live in gic.c.
>>> Move the functionality of this function into its only caller in vgic.c
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>
>> The reason why gic_clear_pending_irqs is in gic.c is that lr_mask and
>> lr_pending are considered part of the gic driver (gic.c). On the other
>> end, inflight is part of the vgic.
>>
>> As an example, the idea is that the code outside of gic.c (for example
>> vgic.c) shouldn't have to know, or have to care, whether a given IRQ is
>> in the lr_pending queue or actually in a LR register.
> 
> I can understand that the lr_pending queue *should* be logical
> continuation of the LR registers, something like spill-over LRs.
> Though I wasn't aware of this before ;-)
> So I can see that from a *logical* point of view it looks like it
> belongs to the hardware part of the GIC (more specifically gic-vgic.c),
> which deals with the actual LRs. But I guess this is somewhat of a grey
> area.
> 
> BUT:
> This is a design choice of the VGIC, and one which the KVM VGIC design
> for instance does *not* share. Also my earlier Xen VGIC rework patches
> got rid of this as well (because dealing with two lists is too complicated).
> Also, the name is misleading: gic_clear_pending_irqs() does not hint at
> all that this is dealing with the GIC emulation, I think it should read
> vgic_vcpu_clear_pending_irqs().
> And as it accesses VGIC specific data structures only, I don't think it
> belongs to gic.c, really.
> So I could live with moving it into the new gic-vgic.c, let me see if
> that works.
> 
> The need for this patch didn't come out of the blue, I actually need it
> to be able to reuse gic.c with *any* other VGIC implementation. And this
> applies to both a VGIC rework and the KVM VGIC port.
> These lr_queue and lr_pending queues are really an implementation detail
> of the existing *VGIC*, and, more importantly: they refer to the struct
> pending_irq, which is definitely a VGIC detail.
> 
> The rabbit to follow in this series is to strictly split the usage of
> struct pending_irq from the hardware GIC driver. The KVM VGIC does not
> have a "struct pending_irq", so we can't have anything mentioning that
> in code that should survive a KVM VGIC port.
> So short of replacing gic.c at all, moving everything mentioning
> pending_irq out of gic.c is the only option.

Having said that I just moved it to gic-vgic.c, where it's also you of
the way. With this code eventually being removed anyway sometimes in the
future, it's not really worth arguing about it.

Cheers,
Andre.

>> lr_mask and lr_pending are only accessed from gic.c. The only exception
>> is the initialization (INIT_LIST_HEAD(&v->arch.vgic.lr_pending)).
>>
>>
>>> ---
>>>  xen/arch/arm/gic.c        | 11 -----------
>>>  xen/arch/arm/vgic.c       |  4 +++-
>>>  xen/include/asm-arm/gic.h |  1 -
>>>  3 files changed, 3 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index ed363f6c37..75b2e0e0ca 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -675,17 +675,6 @@ out:
>>>      spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>>>  }
>>>  
>>> -void gic_clear_pending_irqs(struct vcpu *v)
>>> -{
>>> -    struct pending_irq *p, *t;
>>> -
>>> -    ASSERT(spin_is_locked(&v->arch.vgic.lock));
>>> -
>>> -    v->arch.lr_mask = 0;
>>> -    list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>>> -        gic_remove_from_lr_pending(v, p);
>>> -}
>>> -
>>>  int gic_events_need_delivery(void)
>>>  {
>>>      struct vcpu *v = current;
>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>> index d8acbbeaaa..451a306a98 100644
>>> --- a/xen/arch/arm/vgic.c
>>> +++ b/xen/arch/arm/vgic.c
>>> @@ -504,7 +504,9 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>>      list_for_each_entry_safe ( p, t, &v->arch.vgic.inflight_irqs, inflight )
>>>          list_del_init(&p->inflight);
>>> -    gic_clear_pending_irqs(v);
>>> +    list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
>>> +        gic_remove_from_lr_pending(v, p);
>>> +    v->arch.lr_mask = 0;
>>>      spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>>>  }
>>>  
>>> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
>>> index d3d7bda50d..2f248301ce 100644
>>> --- a/xen/include/asm-arm/gic.h
>>> +++ b/xen/include/asm-arm/gic.h
>>> @@ -236,7 +236,6 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
>>>                                struct irq_desc *desc);
>>>  
>>>  extern void gic_inject(void);
>>> -extern void gic_clear_pending_irqs(struct vcpu *v);
>>>  extern int gic_events_need_delivery(void);
>>>  
>>>  extern void init_maintenance_interrupt(void);
>>> -- 
>>> 2.14.1
>>>

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

  parent reply	other threads:[~2017-12-06 18:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 12:48 [PATCH 00/12] ARM: VGIC/GIC separation cleanups Andre Przywara
2017-10-19 12:48 ` [PATCH 01/12] ARM: remove unneeded gic.h inclusions Andre Przywara
2017-10-25 23:55   ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 02/12] ARM: vGIC: fix nr_irq definition Andre Przywara
2017-10-26  0:00   ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 03/12] ARM: VGIC: remove gic_clear_pending_irqs() Andre Przywara
2017-10-26  0:14   ` Stefano Stabellini
2017-11-10 16:42     ` Andre Przywara
2017-11-16  1:17       ` Stefano Stabellini
2017-11-16 14:32         ` Julien Grall
2017-12-06 18:01       ` Andre Przywara [this message]
2017-10-19 12:48 ` [PATCH 04/12] ARM: VGIC: move gic_remove_irq_from_queues() Andre Przywara
2017-10-26  0:19   ` Stefano Stabellini
2017-10-26  8:22     ` Julien Grall
2017-11-10 17:14     ` Andre Przywara
2017-11-10 19:04       ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 05/12] ARM: VGIC: move gic_remove_from_lr_pending() Andre Przywara
2017-10-26  0:20   ` Stefano Stabellini
2017-12-06 18:02     ` Andre Przywara
2017-10-19 12:48 ` [PATCH 06/12] ARM: VGIC: streamline gic_restore_pending_irqs() Andre Przywara
2017-10-19 12:48 ` [PATCH 07/12] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation Andre Przywara
2017-10-26  0:37   ` Stefano Stabellini
2017-12-06 18:04     ` Andre Przywara
2017-10-19 12:48 ` [PATCH 08/12] ARM: VGIC: split up gic_dump_info() to cover virtual part separately Andre Przywara
2017-10-26  0:41   ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 09/12] ARM: VGIC: rework events_need_delivery() Andre Przywara
2017-10-26  0:47   ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 10/12] ARM: VGIC: factor out vgic_connect_hw_irq() Andre Przywara
2017-10-26  0:49   ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 11/12] ARM: VGIC: factor out vgic_get_hw_irq_desc() Andre Przywara
2017-10-26  0:50   ` Stefano Stabellini
2017-10-19 12:48 ` [PATCH 12/12] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq Andre Przywara
2017-10-26  0:51   ` Stefano Stabellini
2017-10-26  8:28   ` Julien Grall
2017-12-07 18:33     ` Andre Przywara
2017-10-19 15:37 ` [PATCH 00/12] ARM: VGIC/GIC separation cleanups Andre Przywara

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=a7f85279-9dc0-3304-a8b8-547f851b2581@linaro.org \
    --to=andre.przywara@linaro.org \
    --cc=julien.grall@linaro.org \
    --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 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).