From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
xen-devel@lists.xensource.com
Cc: julien.grall@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [PATCH v8 09/13] xen/arm: second irq injection while the first irq is still inflight
Date: Thu, 22 May 2014 16:48:55 +0100 [thread overview]
Message-ID: <537E1C67.2020302@linaro.org> (raw)
In-Reply-To: <1400761950-25035-9-git-send-email-stefano.stabellini@eu.citrix.com>
On 22/05/14 13:32, Stefano Stabellini wrote:
> Set GICH_LR_PENDING in the corresponding GICH_LR to inject a second irq
> while the first one is still active.
> If the first irq is already pending (not active), clear
> GIC_IRQ_GUEST_QUEUED because the guest doesn't need a second
> notification.If the irq has already been EOI'ed then just clear the
> GICH_LR right away and move the interrupt to lr_pending so that it is
> going to be reinjected by gic_restore_pending_irqs on return to guest.
>
> If the target cpu is not the current cpu, then set GIC_IRQ_GUEST_QUEUED
> and send an SGI. The target cpu is going to be interrupted and call
> gic_clear_lrs, that is going to take the same actions.
>
> Do not call vgic_vcpu_inject_irq from gic_inject if
> evtchn_upcall_pending is set. If we remove that call, we don't need to
> special case evtchn_irq in vgic_vcpu_inject_irq anymore.
> We need to force the first injection of evtchn_irq (call
> gic_vcpu_inject_irq) from vgic_enable_irqs because evtchn_upcall_pending
> is already set by common code on vcpu creation.
If you only need it for the first time. Why can't you call
vgic_inject_irq with the IRQ evtchn when the VCPU is turn on?
This would remove every hack with this IRQ in the GIC code.
> ---
> xen/arch/arm/gic.c | 48 +++++++++++++++++++++++++++++++++++++--------
> xen/arch/arm/vgic.c | 11 +++++++----
> xen/include/asm-arm/gic.h | 1 +
> 3 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 89d7025..a6fe566 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -66,6 +66,8 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> /* Maximum cpu interface per GIC */
> #define NR_GIC_CPU_IF 8
>
> +#undef GIC_DEBUG
>+
Did you intend to keep the debug in the final patch?
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-05-22 15:48 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 12:31 [PATCH v8 0/13] remove maintenance interrupts Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 01/13] xen/arm: no need to set HCR_VI when using the vgic to inject irqs Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 02/13] xen/arm: remove unused virtual parameter from vgic_vcpu_inject_irq Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 03/13] xen/arm: set GICH_HCR_UIE if all the LRs are in use Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 04/13] xen/arm: support HW interrupts, do not request maintenance_interrupts Stefano Stabellini
2014-05-22 15:31 ` Julien Grall
2014-05-22 12:32 ` [PATCH v8 05/13] xen/arm: nr_lrs should be uint8_t Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 06/13] xen/arm: keep track of the GICH_LR used for the irq in struct pending_irq Stefano Stabellini
2014-05-22 15:37 ` Julien Grall
2014-05-22 12:32 ` [PATCH v8 07/13] xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 08/13] xen/arm: rename GIC_IRQ_GUEST_PENDING to GIC_IRQ_GUEST_QUEUED Stefano Stabellini
2014-05-22 15:39 ` Julien Grall
2014-06-06 15:15 ` Ian Campbell
2014-05-22 12:32 ` [PATCH v8 09/13] xen/arm: second irq injection while the first irq is still inflight Stefano Stabellini
2014-05-22 15:48 ` Julien Grall [this message]
2014-05-22 17:39 ` Stefano Stabellini
2014-05-22 18:05 ` Julien Grall
2014-05-23 14:50 ` Stefano Stabellini
2014-05-23 15:14 ` Julien Grall
2014-05-23 17:24 ` Stefano Stabellini
2014-05-25 18:46 ` Julien Grall
2014-05-27 16:53 ` Stefano Stabellini
2014-06-06 15:25 ` Ian Campbell
2014-06-09 10:34 ` Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 10/13] xen/arm: don't protect GICH and lr_queue accesses with gic.lock Stefano Stabellini
2014-05-22 16:04 ` Julien Grall
2014-05-22 12:32 ` [PATCH v8 11/13] xen/arm: gic_events_need_delivery and irq priorities Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 12/13] xen/arm: introduce GIC_PRI_TO_GUEST macro Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 13/13] gic_remove_from_queues: take a lock on the right vcpu Stefano Stabellini
2014-05-22 16:10 ` Julien Grall
2014-05-22 17:45 ` Stefano Stabellini
2014-05-22 18:10 ` Julien Grall
2014-05-23 17:33 ` Stefano Stabellini
2014-05-23 17:46 ` Julien Grall
2014-05-25 15:39 ` Stefano Stabellini
2014-05-25 17:37 ` Julien Grall
2014-05-25 17:44 ` Stefano Stabellini
2014-05-25 17:54 ` Stefano Stabellini
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=537E1C67.2020302@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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).