xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Andre Przywara <andre.przywara@linaro.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH 24/49] ARM: new VGIC: Add IRQ sync/flush framework
Date: Tue, 13 Feb 2018 12:41:06 +0000	[thread overview]
Message-ID: <0a43b818-ed1c-baac-7304-e46573a368b7@arm.com> (raw)
In-Reply-To: <20180209143937.28866-25-andre.przywara@linaro.org>

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:
> Implement the framework for syncing IRQs between our emulation and the
> list registers, which represent the guest's view of IRQs.
> This is done in kvm_vgic_flush_hwstate and kvm_vgic_sync_hwstate, which

You probably want to update the names here.

> gets called on guest entry and exit.
> The code talking to the actual GICv2/v3 hardware is added in the
> following patches.
> 
> This is based on Linux commit 0919e84c0fc1, written by Marc Zyngier.
> 
> Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
> ---
>   xen/arch/arm/vgic/vgic.c | 246 +++++++++++++++++++++++++++++++++++++++++++++++
>   xen/arch/arm/vgic/vgic.h |   2 +
>   2 files changed, 248 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index a4efd1fd03..a1f77130d4 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/xen/arch/arm/vgic/vgic.c
> @@ -380,6 +380,252 @@ int vgic_inject_irq(struct domain *d, struct vcpu *vcpu, unsigned int intid,
>       return 0;
>   }
>   
> +/**
> + * vgic_prune_ap_list - Remove non-relevant interrupts from the list
> + *
> + * @vcpu: The VCPU pointer
> + *
> + * Go over the list of "interesting" interrupts, and prune those that we
> + * won't have to consider in the near future.
> + */
> +static void vgic_prune_ap_list(struct vcpu *vcpu)
> +{
> +    struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> +    struct vgic_irq *irq, *tmp;
> +    unsigned long flags;
> +
> +retry:
> +    spin_lock_irqsave(&vgic_cpu->ap_list_lock, flags);
> +
> +    list_for_each_entry_safe( irq, tmp, &vgic_cpu->ap_list_head, ap_list )

See my comment on patch #22, this is where I am worry about going 
through the list every time we enter to the hypervisor from the guest.

> +    {
> +        struct vcpu *target_vcpu, *vcpuA, *vcpuB;
> +
> +        spin_lock(&irq->irq_lock);
> +
> +        BUG_ON(vcpu != irq->vcpu);
> +
> +        target_vcpu = vgic_target_oracle(irq);
> +
> +        if ( !target_vcpu )
> +        {
> +            /*
> +             * We don't need to process this interrupt any
> +             * further, move it off the list.
> +             */
> +            list_del(&irq->ap_list);
> +            irq->vcpu = NULL;
> +            spin_unlock(&irq->irq_lock);
> +
> +            /*
> +             * This vgic_put_irq call matches the
> +             * vgic_get_irq_kref in vgic_queue_irq_unlock,
> +             * where we added the LPI to the ap_list. As
> +             * we remove the irq from the list, we drop
> +             * also drop the refcount.
> +             */
> +            vgic_put_irq(vcpu->domain, irq);
> +            continue;
> +        }
> +
> +        if ( target_vcpu == vcpu )
> +        {
> +            /* We're on the right CPU */
> +            spin_unlock(&irq->irq_lock);
> +            continue;
> +        }
> +
> +        /* This interrupt looks like it has to be migrated. */
> +
> +        spin_unlock(&irq->irq_lock);
> +        spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
> +
> +        /*
> +         * Ensure locking order by always locking the smallest
> +         * ID first.
> +         */
> +        if ( vcpu->vcpu_id < target_vcpu->vcpu_id )
> +        {
> +            vcpuA = vcpu;
> +            vcpuB = target_vcpu;
> +        }
> +        else
> +        {
> +            vcpuA = target_vcpu;
> +            vcpuB = vcpu;
> +        }
> +
> +        spin_lock_irqsave(&vcpuA->arch.vgic_cpu.ap_list_lock, flags);
> +        spin_lock(&vcpuB->arch.vgic_cpu.ap_list_lock);
> +        spin_lock(&irq->irq_lock);
> +
> +        /*
> +         * If the affinity has been preserved, move the
> +         * interrupt around. Otherwise, it means things have
> +         * changed while the interrupt was unlocked, and we
> +         * need to replay this.
> +         *
> +         * In all cases, we cannot trust the list not to have
> +         * changed, so we restart from the beginning.
> +         */
> +        if ( target_vcpu == vgic_target_oracle(irq) )
> +        {
> +            struct vgic_cpu *new_cpu = &target_vcpu->arch.vgic_cpu;
> +
> +            list_del(&irq->ap_list);
> +            irq->vcpu = target_vcpu;
> +            list_add_tail(&irq->ap_list, &new_cpu->ap_list_head);
> +        }
> +
> +        spin_unlock(&irq->irq_lock);
> +        spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
> +        spin_unlock_irqrestore(&vcpuA->arch.vgic_cpu.ap_list_lock, flags);
> +        goto retry;
> +    }
> +
> +    spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
> +}
> +
> +static inline void vgic_fold_lr_state(struct vcpu *vcpu)
> +{
> +}
> +
> +/* Requires the irq_lock to be held. */
> +static inline void vgic_populate_lr(struct vcpu *vcpu,
> +                                    struct vgic_irq *irq, int lr)
> +{
> +    ASSERT(spin_is_locked(&irq->irq_lock));
> +}
> +
> +static inline void vgic_clear_lr(struct vcpu *vcpu, int lr)
> +{
> +}
> +
> +static inline void vgic_set_underflow(struct vcpu *vcpu)
> +{
> +}
> +
> +/* Requires the ap_list_lock to be held. */
> +static int compute_ap_list_depth(struct vcpu *vcpu)
> +{
> +    struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> +    struct vgic_irq *irq;
> +    int count = 0;
> +
> +    ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
> +
> +    list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list)

Here another example.

> +    {
> +        spin_lock(&irq->irq_lock);
> +        /* GICv2 SGIs can count for more than one... */
> +        if ( vgic_irq_is_sgi(irq->intid) && irq->source )
> +            count += hweight8(irq->source);
> +        else
> +            count++;
> +        spin_unlock(&irq->irq_lock);
> +    }
> +    return count;
> +}
> +
> +/* Requires the VCPU's ap_list_lock to be held. */
> +static void vgic_flush_lr_state(struct vcpu *vcpu)
> +{
> +    struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> +    struct vgic_irq *irq;
> +    int count = 0;
> +
> +    ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
> +
> +    if ( compute_ap_list_depth(vcpu) > gic_get_nr_lrs() )
> +        vgic_sort_ap_list(vcpu);
> +
> +    list_for_each_entry( irq, &vgic_cpu->ap_list_head, ap_list )
> +    {
> +        spin_lock(&irq->irq_lock);
> +
> +        if ( unlikely(vgic_target_oracle(irq) != vcpu) )
> +            goto next;
> +
> +        /*
> +         * If we get an SGI with multiple sources, try to get
> +         * them in all at once.
> +         */
> +        do
> +        {
> +            vgic_populate_lr(vcpu, irq, count++);
> +        } while ( irq->source && count < gic_get_nr_lrs() );
> +
> +next:
> +        spin_unlock(&irq->irq_lock);
> +
> +        if ( count == gic_get_nr_lrs() )
> +        {
> +            if ( !list_is_last(&irq->ap_list, &vgic_cpu->ap_list_head) )
> +                vgic_set_underflow(vcpu);
> +            break;
> +        }
> +    }
> +
> +    vcpu->arch.vgic_cpu.used_lrs = count;
> +
> +    /* Nuke remaining LRs */
> +    for ( ; count < gic_get_nr_lrs(); count++)
> +        vgic_clear_lr(vcpu, count);
> +}
> +
> +/*
> + * gic_clear_lrs() - Update the VGIC state from hardware after a guest's run.
> + * @vcpu: the VCPU.
> + *
> + * Sync back the hardware VGIC state after the guest has run, into our
> + * VGIC emulation structures, It reads the LRs and updates the respective
> + * struct vgic_irq, taking level/edge into account.
> + * This is the high level function which takes care of the conditions,
> + * also bails out early if there were no interrupts queued.
> + * Was: kvm_vgic_sync_hwstate()
> + */
> +void gic_clear_lrs(struct vcpu *vcpu)

I think I would prefer if we stick with the KVM name.

> +{
> +    struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> +
> +    /* An empty ap_list_head implies used_lrs == 0 */
> +    if ( list_empty(&vcpu->arch.vgic_cpu.ap_list_head) )
> +        return;
> +
> +    if ( vgic_cpu->used_lrs )
> +        vgic_fold_lr_state(vcpu);
> +    vgic_prune_ap_list(vcpu);
> +}
> +
> +/*
> + * gic_inject() - flush the emulation state into the hardware on guest entry
> + *
> + * Before we enter a guest, we have to translate the virtual GIC state of a
> + * VCPU into the GIC virtualization hardware registers, namely the LRs.
> + * This is the high level function which takes care about the conditions
> + * and the locking, also bails out early if there are no interrupts queued.
> + * Was: kvm_vgic_flush_hwstate()

Ditto.

> + */
> +void gic_inject(void)
> +{
> +    /*
> +     * If there are no virtual interrupts active or pending for this
> +     * VCPU, then there is no work to do and we can bail out without
> +     * taking any lock.  There is a potential race with someone injecting
> +     * interrupts to the VCPU, but it is a benign race as the VCPU will
> +     * either observe the new interrupt before or after doing this check,
> +     * and introducing additional synchronization mechanism doesn't change
> +     * this.
> +     */
> +    if ( list_empty(&current->arch.vgic_cpu.ap_list_head) )
> +        return;
> +
> +    ASSERT(!local_irq_is_enabled());
> +
> +    spin_lock(&current->arch.vgic_cpu.ap_list_lock);
> +    vgic_flush_lr_state(current);
> +    spin_unlock(&current->arch.vgic_cpu.ap_list_lock);
> +}
>   /*
>    * Local variables:
>    * mode: C
> diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
> index 5127739f0f..47fc58b81e 100644
> --- a/xen/arch/arm/vgic/vgic.h
> +++ b/xen/arch/arm/vgic/vgic.h
> @@ -17,6 +17,8 @@
>   #ifndef __XEN_ARM_VGIC_NEW_H__
>   #define __XEN_ARM_VGIC_NEW_H__
>   
> +#define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
> +
>   static inline bool irq_is_pending(struct vgic_irq *irq)
>   {
>       if ( irq->config == VGIC_CONFIG_EDGE )
> 

Cheers,

-- 
Julien Grall

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

  reply	other threads:[~2018-02-13 12:41 UTC|newest]

Thread overview: 154+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-09 14:38 [RFC PATCH 00/49] New VGIC(-v2) implementation Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 01/49] tools: ARM: vGICv3: avoid inserting optional DT properties Andre Przywara
2018-02-09 19:14   ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 02/49] ARM: vGICv3: drop GUEST_GICV3_RDIST_REGIONS symbol Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 03/49] ARM: GICv3: use hardware GICv3 redistributor regions for Dom0 Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 04/49] ARM: GICv3: simplify GICv3 redistributor stride handling Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 05/49] ARM: vGICv3: always use architected redist stride Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 06/49] ARM: vGICv3: remove rdist_stride from VGIC structure Andre Przywara
2018-02-09 14:38 ` [RFC PATCH 07/49] ARM: VGIC: move gic_remove_from_lr_pending() prototype Andre Przywara
2018-02-09 19:15   ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 08/49] ARM: VGIC: move max_vcpus VGIC limit to struct arch_domain Andre Przywara
2018-02-09 19:27   ` Julien Grall
2018-02-28 12:32     ` Andre Przywara
2018-02-28 13:04       ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 09/49] ARM: VGIC: change to level-IRQ compatible IRQ injection interface Andre Przywara
2018-02-12 11:15   ` Julien Grall
2018-02-12 11:59     ` Andre Przywara
2018-02-12 12:19       ` Julien Grall
2018-02-12 14:24         ` Andre Przywara
2018-02-13 11:49           ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 10/49] ARM: VGIC: carve out struct vgic_cpu and struct vgic_dist Andre Przywara
2018-02-12 11:19   ` Julien Grall
2018-02-09 14:38 ` [RFC PATCH 11/49] ARM: VGIC: reorder prototypes in vgic.h Andre Przywara
2018-02-12 11:53   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 12/49] ARM: VGIC: introduce gic_get_nr_lrs() Andre Przywara
2018-02-12 11:57   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 13/49] ARM: VGIC: Add hypervisor base address to vgic_v2_setup_hw() Andre Przywara
2018-02-12 12:07   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 14/49] ARM: VGIC: extend GIC CPU interface definitions Andre Przywara
2018-02-12 12:34   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ Andre Przywara
2018-02-12 13:55   ` Julien Grall
2018-02-12 17:53     ` Andre Przywara
2018-02-13 12:02       ` Julien Grall
2018-02-13 15:01         ` Andre Przywara
2018-02-16 15:07           ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 16/49] ARM: GIC: allow reading pending state of a hardware IRQ Andre Przywara
2018-02-12 14:00   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 17/49] ARM: timer: Handle level triggered IRQs correctly Andre Przywara
2018-02-12 15:19   ` Julien Grall
2018-02-12 18:23     ` Andre Przywara
2018-02-13 12:05       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 18/49] ARM: evtchn: " Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 19/49] ARM: vPL011: Use the VGIC's level triggered IRQs handling if available Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 20/49] ARM: new VGIC: Add data structure definitions Andre Przywara
2018-02-12 16:42   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 21/49] ARM: new VGIC: Add acccessor to new struct vgic_irq instance Andre Przywara
2018-02-12 17:42   ` Julien Grall
2018-02-13 11:18     ` Andre Przywara
2018-02-16 15:16       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 22/49] ARM: new VGIC: Implement virtual IRQ injection Andre Przywara
2018-02-12 18:59   ` Julien Grall
2018-02-27 10:17     ` Andre Przywara
2018-02-27 10:43       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 23/49] ARM: new VGIC: Add IRQ sorting Andre Przywara
2018-02-13 12:30   ` Julien Grall
2018-02-13 14:56     ` Andre Przywara
2018-02-13 15:00       ` Julien Grall
2018-02-13 16:21       ` Christoffer Dall
2018-02-09 14:39 ` [RFC PATCH 24/49] ARM: new VGIC: Add IRQ sync/flush framework Andre Przywara
2018-02-13 12:41   ` Julien Grall [this message]
2018-02-13 15:40     ` Andre Przywara
2018-02-16 15:22       ` Julien Grall
2018-02-13 14:31   ` Julien Grall
2018-02-13 14:56     ` Andre Przywara
2018-02-13 15:01       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 25/49] ARM: new VGIC: Add GICv2 world switch backend Andre Przywara
2018-02-13 14:31   ` Julien Grall
2018-02-26 15:13     ` Andre Przywara
2018-02-26 16:02       ` Julien Grall
2018-02-26 16:19         ` Andre Przywara
2018-02-26 15:16     ` Andre Przywara
2018-02-26 15:59       ` Julien Grall
2018-02-26 16:23         ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 26/49] ARM: new VGIC: Implement vgic_vcpu_pending_irq Andre Przywara
2018-02-13 16:35   ` Julien Grall
2018-02-13 16:36     ` Julien Grall
2018-02-26 15:29     ` Andre Przywara
2018-02-26 15:55       ` Julien Grall
2018-02-26 16:25         ` Andre Przywara
2018-02-26 16:30           ` Julien Grall
2018-03-02 13:53             ` Andre Przywara
2018-03-02 13:58               ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 27/49] ARM: new VGIC: Add MMIO handling framework Andre Przywara
2018-02-13 16:52   ` Julien Grall
2018-02-13 18:17     ` Andre Przywara
2018-02-16 15:25       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 28/49] ARM: new VGIC: Add GICv2 " Andre Przywara
2018-02-16 15:39   ` Julien Grall
2018-02-19 12:23     ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 29/49] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers Andre Przywara
2018-02-16 15:56   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 30/49] ARM: new VGIC: Add ENABLE registers handlers Andre Przywara
2018-02-16 16:57   ` Julien Grall
2018-02-19 12:41     ` Andre Przywara
2018-02-19 14:13       ` Julien Grall
2018-02-27 13:54         ` Andre Przywara
2018-02-27 14:34           ` Julien Grall
2018-02-23 15:18     ` Andre Przywara
2018-02-26 11:20       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 31/49] ARM: new VGIC: Add PENDING " Andre Przywara
2018-02-16 17:16   ` Julien Grall
2018-02-19 15:32     ` Andre Przywara
2018-02-19 15:43       ` Julien Grall
2018-03-02 16:36         ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 32/49] ARM: new VGIC: Add ACTIVE " Andre Przywara
2018-02-16 17:30   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 33/49] ARM: new VGIC: Add PRIORITY " Andre Przywara
2018-02-16 17:38   ` Julien Grall
2018-02-23 14:47     ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 34/49] ARM: new VGIC: Add CONFIG " Andre Przywara
2018-02-19 11:39   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 35/49] ARM: new VGIC: Add TARGET " Andre Przywara
2018-02-19 11:53   ` Julien Grall
2018-02-23 11:25     ` Andre Przywara
2018-02-19 12:30   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 36/49] ARM: new VGIC: Add SGIR register handler Andre Przywara
2018-02-19 11:59   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 37/49] ARM: new VGIC: Add SGIPENDR register handlers Andre Przywara
2018-02-19 12:02   ` Julien Grall
2018-02-23 11:39     ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 38/49] ARM: new VGIC: handle hardware mapped IRQs Andre Przywara
2018-02-19 12:19   ` Julien Grall
2018-02-23 18:02     ` Andre Przywara
2018-02-23 18:14       ` Julien Grall
2018-02-26 16:48         ` Andre Przywara
2018-02-26 16:57           ` Julien Grall
2018-02-26 17:19             ` Andre Przywara
2018-02-26 17:26               ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 39/49] ARM: new VGIC: Add event channel IRQ handling Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 40/49] ARM: new VGIC: Handle virtual IRQ allocation/reservation Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 41/49] ARM: new VGIC: dump virtual IRQ info Andre Przywara
2018-02-19 12:26   ` Julien Grall
2018-02-26 16:58     ` Andre Przywara
2018-02-26 17:01       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 42/49] ARM: new VGIC: provide system register emulation stub Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 43/49] ARM: new VGIC: Add preliminary stub implementations Andre Przywara
2018-02-19 12:34   ` Julien Grall
2018-02-27 17:05     ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 44/49] ARM: new VGIC: vgic-init: register VGIC Andre Przywara
2018-02-19 12:39   ` Julien Grall
2018-02-26 17:33     ` Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 45/49] ARM: new VGIC: vgic-init: implement vgic_init Andre Przywara
2018-02-19 13:21   ` Julien Grall
2018-02-19 15:53     ` Andre Przywara
2018-02-19 15:58       ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 46/49] ARM: new VGIC: vgic-init: implement map_resources Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 47/49] ARM: new VGIC: Add vgic_v2_enable Andre Przywara
2018-02-09 14:39 ` [RFC PATCH 48/49] ARM: allocate two pages for struct vcpu Andre Przywara
2018-02-19 14:07   ` Julien Grall
2018-02-09 14:39 ` [RFC PATCH 49/49] ARM: VGIC: wire new VGIC(-v2) files into Xen build system Andre Przywara
2018-02-09 15:06 ` [RFC PATCH 00/49] New VGIC(-v2) implementation Andre Przywara
2018-02-12 11:48   ` Julien Grall
2018-02-12 11:53     ` 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=0a43b818-ed1c-baac-7304-e46573a368b7@arm.com \
    --to=julien.grall@arm.com \
    --cc=andre.przywara@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).