From: Andre Przywara <andre.przywara@arm.com>
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs
Date: Thu, 3 Nov 2016 19:47:22 +0000 [thread overview]
Message-ID: <55a10bdc-b833-d483-1c1c-f5b0d6f8f278@arm.com> (raw)
In-Reply-To: <CALicx6vVN6jahpOkDrS81Kh6XAK4FLQytTtwF4o0GW78QTKAiQ@mail.gmail.com>
Hi,
On 24/10/16 16:31, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara <andre.przywara@arm.com> 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. However we actually only need those when an
>> interrupt is on a vCPU (or is about to be injected).
>> Maintain a list of those structs that we can use for the lifecycle of
>> a guest LPI. We allocate new entries if necessary, however reuse
>> pre-owned entries whenever possible.
>> Teach the existing VGIC functions to find the right pointer when being
>> given a virtual LPI number.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> xen/arch/arm/gic.c | 3 +++
>> xen/arch/arm/vgic-v3.c | 2 ++
>> xen/arch/arm/vgic.c | 56 ++++++++++++++++++++++++++++++++++++++++---
>> xen/include/asm-arm/domain.h | 1 +
>> xen/include/asm-arm/gic-its.h | 10 ++++++++
>> xen/include/asm-arm/vgic.h | 9 +++++++
>> 6 files changed, 78 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 63c744a..ebe4035 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -506,6 +506,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>> struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
>> irq_set_affinity(p->desc, cpumask_of(v_target->processor));
>> }
>> + /* If this was an LPI, mark this struct as available again. */
>> + if ( p->irq >= 8192 )
> Can define something line is_lpi(irq) and use it everywhere
Yes, that was on my list anyway.
>> + p->irq = 0;
>> }
>> }
>> }
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index ec038a3..e9b6490 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -1388,6 +1388,8 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
>> if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
>> v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
>>
>> + INIT_LIST_HEAD(&v->arch.vgic.pending_lpi_list);
>> +
>> return 0;
>> }
>>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 0965119..b961551 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -31,6 +31,8 @@
>> #include <asm/mmio.h>
>> #include <asm/gic.h>
>> #include <asm/vgic.h>
>> +#include <asm/gic_v3_defs.h>
>> +#include <asm/gic-its.h>
>>
>> static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int rank)
>> {
>> @@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq)
>> return vgic_get_rank(v, rank);
>> }
>>
>> -static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
>> +void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
>> {
>> INIT_LIST_HEAD(&p->inflight);
>> INIT_LIST_HEAD(&p->lr_queue);
>> @@ -244,10 +246,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq)
>>
>> static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>> {
>> - struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>> + struct vgic_irq_rank *rank;
>> unsigned long flags;
>> int priority;
>>
>> + if ( virq >= 8192 )
>> + return gicv3_lpi_get_priority(v->domain, virq);
>> +
>> + rank = vgic_rank_irq(v, virq);
>> vgic_lock_rank(v, rank, flags);
>> priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>> vgic_unlock_rank(v, rank, flags);
>> @@ -446,13 +452,55 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, int
>> return 1;
>> }
>>
>> +/*
>> + * Holding struct pending_irq's for each possible virtual LPI in each domain
>> + * requires too much Xen memory, also a malicious guest could potentially
>> + * spam Xen with LPI map requests. We cannot cover those with (guest allocated)
>> + * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
>> + * on demand.
>> + */
>> +struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
>> + bool allocate)
>> +{
>> + struct lpi_pending_irq *lpi_irq, *empty = NULL;
>> +
>> + /* TODO: locking! */
>> + list_for_each_entry(lpi_irq, &v->arch.vgic.pending_lpi_list, entry)
>> + {
>> + if ( lpi_irq->pirq.irq == lpi )
>> + return &lpi_irq->pirq;
>> +
>> + if ( lpi_irq->pirq.irq == 0 && !empty )
>> + empty = lpi_irq;
>> + }
> With this approach of allocating pending_irq on demand, if the
> pending_lpi_list
> is at n position then it iterates for long time to find pending_irq entry.
> This will increase LPI injection time to domain.
>
> Why can't we use btree?
That's an optimization. You will find that the actual number of
interrupts on a VCPU at any given time is very low, especially if we
look at LPIs only. So my hunch is that it's either 0, 1 or 2, not more.
So for simplicity I'd keep it as a list for now. If we see issues, we
can amend this at any time.
>> +
>> + if ( !allocate )
>> + return NULL;
>> +
>> + if ( !empty )
>> + {
>> + empty = xzalloc(struct lpi_pending_irq);
>> + vgic_init_pending_irq(&empty->pirq, lpi);
>> + list_add_tail(&empty->entry, &v->arch.vgic.pending_lpi_list);
>> + } else
>> + {
>> + empty->pirq.status = 0;
>> + empty->pirq.irq = lpi;
>> + }
>> +
>> + return &empty->pirq;
>> +}
>> +
>> struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>> {
>> struct pending_irq *n;
>> +
>> /* 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];
>> + else if ( irq >= 8192 )
>> + n = lpi_to_pending(v, irq, true);
>> else
>> n = &v->domain->arch.vgic.pending_irqs[irq - 32];
>> return n;
>> @@ -480,7 +528,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_t running;
>>
>> @@ -488,6 +536,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) )
>> {
>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>> index 9452fcd..ae8a9de 100644
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -249,6 +249,7 @@ struct arch_vcpu
>> paddr_t rdist_base;
>> #define VGIC_V3_RDIST_LAST (1 << 0) /* last vCPU of the rdist */
>> uint8_t flags;
>> + struct list_head pending_lpi_list;
>> } vgic;
>>
>> /* Timer registers */
>> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
>> index 4e9841a..1f881c0 100644
>> --- a/xen/include/asm-arm/gic-its.h
>> +++ b/xen/include/asm-arm/gic-its.h
>> @@ -136,6 +136,12 @@ int gicv3_lpi_allocate_host_lpi(struct host_its *its,
>> int gicv3_lpi_drop_host_lpi(struct host_its *its,
>> uint32_t devid, uint32_t eventid,
>> uint32_t host_lpi);
>> +
>> +static inline int gicv3_lpi_get_priority(struct domain *d, uint32_t lpi)
>> +{
>> + return GIC_PRI_IRQ;
> Why lpi priority is fixed?. can't we use domain set lpi priority?
Mmh, looks like a rebase artifact. It is fixed if the ITS isn't
configured, but should just be the prototype if not.
The final file has it right, so I guess this gets amended in some later
patch. Thanks for spotting this.
Cheers,
Andre.
>> +}
>> +
>> #else
>>
>> static inline void gicv3_its_dt_init(const struct dt_device_node *node)
>> @@ -175,6 +181,10 @@ static inline int gicv3_lpi_drop_host_lpi(struct host_its *its,
>> {
>> return 0;
>> }
>> +static inline int gicv3_lpi_get_priority(struct domain *d, uint32_t lpi)
>> +{
>> + return GIC_PRI_IRQ;
>> +}
>>
>> #endif /* CONFIG_HAS_ITS */
>>
>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>> index 300f461..4e29ba6 100644
>> --- a/xen/include/asm-arm/vgic.h
>> +++ b/xen/include/asm-arm/vgic.h
>> @@ -83,6 +83,12 @@ struct pending_irq
>> struct list_head lr_queue;
>> };
>>
>> +struct lpi_pending_irq
>> +{
>> + struct list_head entry;
>> + struct pending_irq pirq;
>> +};
>> +
>> #define NR_INTERRUPT_PER_RANK 32
>> #define INTERRUPT_RANK_MASK (NR_INTERRUPT_PER_RANK - 1)
>>
>> @@ -296,8 +302,11 @@ extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq);
>> extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
>> extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
>> extern void vgic_clear_pending_irqs(struct vcpu *v);
>> +extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
>> 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 vcpu *v, unsigned int irq,
>> + bool allocate);
>> 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 int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
>> --
>> 2.9.0
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-11-03 19:46 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-28 18:24 [RFC PATCH 00/24] [FOR 4.9] arm64: Dom0 ITS emulation Andre Przywara
2016-09-28 18:24 ` [RFC PATCH 01/24] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT Andre Przywara
2016-10-26 1:11 ` Stefano Stabellini
2016-11-01 15:13 ` Julien Grall
2016-11-14 17:35 ` Andre Przywara
2016-11-23 15:39 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table Andre Przywara
2016-10-24 14:28 ` Vijay Kilari
2016-11-02 16:22 ` Andre Przywara
2016-10-26 1:10 ` Stefano Stabellini
2016-11-10 15:29 ` Andre Przywara
2016-11-10 21:00 ` Stefano Stabellini
2016-11-01 17:22 ` Julien Grall
2016-11-15 11:32 ` Andre Przywara
2016-11-23 15:58 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 03/24] ARM: GICv3 ITS: allocate device and collection table Andre Przywara
2016-10-09 13:55 ` Vijay Kilari
2016-10-10 9:05 ` Andre Przywara
2016-10-24 14:30 ` Vijay Kilari
2016-11-02 17:51 ` Andre Przywara
2016-10-26 22:57 ` Stefano Stabellini
2016-11-01 17:34 ` Julien Grall
2016-11-10 15:32 ` Andre Przywara
2016-11-10 21:06 ` Stefano Stabellini
2016-11-01 18:19 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 04/24] ARM: GICv3 ITS: map ITS command buffer Andre Przywara
2016-10-24 14:31 ` Vijay Kilari
2016-10-26 23:03 ` Stefano Stabellini
2016-11-10 16:04 ` Andre Przywara
2016-11-02 13:38 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 05/24] ARM: GICv3 ITS: introduce ITS command handling Andre Przywara
2016-10-26 23:55 ` Stefano Stabellini
2016-10-27 21:52 ` Stefano Stabellini
2016-11-10 15:57 ` Andre Przywara
2016-11-02 15:05 ` Julien Grall
2017-01-31 9:10 ` Andre Przywara
2017-01-31 10:23 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 06/24] ARM: GICv3 ITS: introduce host LPI array Andre Przywara
2016-10-27 22:59 ` Stefano Stabellini
2016-11-02 15:14 ` Julien Grall
2016-11-10 17:22 ` Andre Przywara
2016-11-10 21:48 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 07/24] ARM: GICv3 ITS: introduce device mapping Andre Przywara
2016-10-24 15:31 ` Vijay Kilari
2016-11-03 19:33 ` Andre Przywara
2016-10-28 0:08 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs Andre Przywara
2016-10-24 15:31 ` Vijay Kilari
2016-11-03 19:47 ` Andre Przywara [this message]
2016-10-28 1:04 ` Stefano Stabellini
2017-01-12 19:14 ` Andre Przywara
2017-01-13 19:37 ` Stefano Stabellini
2017-01-16 9:44 ` André Przywara
2017-01-16 19:16 ` Stefano Stabellini
2016-11-04 15:46 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 09/24] ARM: GICv3: forward pending LPIs to guests Andre Przywara
2016-10-28 1:51 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 10/24] ARM: GICv3: enable ITS and LPIs on the host Andre Przywara
2016-10-28 23:07 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 11/24] ARM: vGICv3: handle virtual LPI pending and property tables Andre Przywara
2016-10-24 15:32 ` Vijay Kilari
2016-11-03 20:21 ` Andre Przywara
2016-11-04 11:53 ` Julien Grall
2016-10-29 0:39 ` Stefano Stabellini
2017-03-29 15:47 ` Andre Przywara
2016-11-02 17:18 ` Julien Grall
2016-11-02 17:41 ` Stefano Stabellini
2016-11-02 18:03 ` Julien Grall
2016-11-02 18:09 ` Stefano Stabellini
2017-01-31 9:10 ` Andre Przywara
2017-01-31 10:38 ` Julien Grall
2017-01-31 12:04 ` Andre Przywara
2016-09-28 18:24 ` [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits Andre Przywara
2016-10-09 14:20 ` Vijay Kilari
2016-10-10 10:38 ` Andre Przywara
2016-10-24 15:31 ` Vijay Kilari
2016-11-03 19:26 ` Andre Przywara
2016-11-04 12:07 ` Julien Grall
2016-11-03 17:50 ` Julien Grall
2016-11-08 23:54 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 13/24] ARM: vITS: handle CLEAR command Andre Przywara
2016-11-04 15:48 ` Julien Grall
2016-11-09 0:39 ` Stefano Stabellini
2016-11-09 13:32 ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 14/24] ARM: vITS: handle INT command Andre Przywara
2016-11-09 0:42 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 15/24] ARM: vITS: handle MAPC command Andre Przywara
2016-11-09 0:48 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 16/24] ARM: vITS: handle MAPD command Andre Przywara
2016-11-09 0:54 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 17/24] ARM: vITS: handle MAPTI command Andre Przywara
2016-11-09 1:07 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 18/24] ARM: vITS: handle MOVI command Andre Przywara
2016-11-09 1:13 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 19/24] ARM: vITS: handle DISCARD command Andre Przywara
2016-11-09 1:28 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 20/24] ARM: vITS: handle INV command Andre Przywara
2016-11-09 1:49 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 21/24] ARM: vITS: handle INVALL command Andre Przywara
2016-10-24 15:32 ` Vijay Kilari
2016-11-04 9:22 ` Andre Przywara
2016-11-10 0:21 ` Stefano Stabellini
2016-11-10 11:57 ` Julien Grall
2016-11-10 20:42 ` Stefano Stabellini
2016-11-11 15:53 ` Julien Grall
2016-11-11 20:31 ` Stefano Stabellini
2016-11-18 18:39 ` Stefano Stabellini
2016-11-25 16:10 ` Julien Grall
2016-12-01 1:19 ` Stefano Stabellini
2016-12-02 16:18 ` Andre Przywara
2016-12-03 0:46 ` Stefano Stabellini
2016-12-05 13:36 ` Julien Grall
2016-12-05 19:51 ` Stefano Stabellini
2016-12-06 15:56 ` Julien Grall
2016-12-06 19:36 ` Stefano Stabellini
2016-12-06 21:32 ` Dario Faggioli
2016-12-06 21:53 ` Stefano Stabellini
2016-12-06 22:01 ` Stefano Stabellini
2016-12-06 22:12 ` Dario Faggioli
2016-12-06 23:13 ` Julien Grall
2016-12-07 20:20 ` Stefano Stabellini
2016-12-09 18:01 ` Julien Grall
2016-12-09 20:13 ` Stefano Stabellini
2016-12-09 18:07 ` Andre Przywara
2016-12-09 20:18 ` Stefano Stabellini
2016-12-14 2:39 ` George Dunlap
2016-12-16 1:30 ` Dario Faggioli
2016-12-06 22:39 ` Dario Faggioli
2016-12-06 23:24 ` Julien Grall
2016-12-07 0:17 ` Dario Faggioli
2016-12-07 20:21 ` Stefano Stabellini
2016-12-09 10:14 ` Dario Faggioli
2016-12-06 21:36 ` Dario Faggioli
2016-12-09 19:00 ` Andre Przywara
2016-12-10 0:30 ` Stefano Stabellini
2016-12-12 10:38 ` Andre Przywara
2016-12-14 0:38 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 22/24] ARM: vITS: create and initialize virtual ITSes for Dom0 Andre Przywara
2016-11-10 0:38 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 23/24] ARM: vITS: create ITS subnodes for Dom0 DT Andre Przywara
2016-09-28 18:24 ` [RFC PATCH 24/24] ARM: vGIC: advertising LPI support Andre Przywara
2016-11-10 0:49 ` Stefano Stabellini
2016-11-10 11:22 ` Julien Grall
2016-11-02 13:56 ` [RFC PATCH 00/24] [FOR 4.9] 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=55a10bdc-b833-d483-1c1c-f5b0d6f8f278@arm.com \
--to=andre.przywara@arm.com \
--cc=julien.grall@arm.com \
--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).