From: Marc Zyngier <marc.zyngier@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Cc: Eric Auger <eric.auger@redhat.com>,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 13/17] KVM: arm64: read initial LPI pending table
Date: Mon, 11 Jul 2016 17:50:47 +0100 [thread overview]
Message-ID: <5783CE67.2070202@arm.com> (raw)
In-Reply-To: <20160705112309.28877-14-andre.przywara@arm.com>
On 05/07/16 12:23, Andre Przywara wrote:
> The LPI pending status for a GICv3 redistributor is held in a table
> in (guest) memory. To achieve reasonable performance, we cache this
> data in our struct vgic_irq. The initial pending state must be read
> from guest memory upon enabling LPIs for this redistributor.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 81 ++++++++++++++++++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.h | 6 ++++
> 2 files changed, 87 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index 1e2e649..29bb4fe 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -93,6 +93,81 @@ struct its_itte {
> list_for_each_entry(itte, &(dev)->itt_head, itte_list)
>
> #define CBASER_ADDRESS(x) ((x) & GENMASK_ULL(51, 12))
> +#define PENDBASER_ADDRESS(x) ((x) & GENMASK_ULL(51, 16))
52 bits again. Pick a side!
> +
> +static int vgic_its_copy_lpi_list(struct kvm *kvm, u32 **intid_ptr)
> +{
> + struct vgic_dist *dist = &kvm->arch.vgic;
> + struct vgic_irq *irq;
> + u32 *intids;
> + int irq_count = dist->lpi_list_count, i = 0;
> +
> + /*
> + * We use the current value of the list length, which may change
> + * after the kmalloc. We don't care, because the guest shouldn't
> + * change anything while the command handling is still running,
> + * and in the worst case we would miss a new IRQ, which one wouldn't
> + * expect to be covered by this command anyway.
> + */
> + intids = kmalloc_array(irq_count, sizeof(intids[0]), GFP_KERNEL);
> + if (!intids)
> + return -ENOMEM;
> +
> + spin_lock(&dist->lpi_list_lock);
> + list_for_each_entry(irq, &dist->lpi_list_head, lpi_entry) {
> + if (kref_get_unless_zero(&irq->refcount)) {
> + intids[i] = irq->intid;
> + vgic_put_irq_locked(kvm, irq);
This is ugly. You know you're not going to free the irq, since it was at
least one when you did kref_get_unless_zero(). Why not doing a simple
kref_put (possibly in a macro so that you can hide the dummy release
function)?
> + }
> + if (i++ == irq_count)
> + break;
> + }
> + spin_unlock(&dist->lpi_list_lock);
> +
> + *intid_ptr = intids;
> + return irq_count;
> +}
> +
> +/*
> + * Scan the whole LPI pending table and sync the pending bit in there
> + * with our own data structures. This relies on the LPI being
> + * mapped before.
> + */
> +static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
> +{
> + gpa_t pendbase = PENDBASER_ADDRESS(vcpu->arch.vgic_cpu.pendbaser);
> + struct vgic_irq *irq;
> + u8 pendmask;
> + int ret = 0;
> + u32 *intids;
> + int nr_irqs, i;
> +
> + nr_irqs = vgic_its_copy_lpi_list(vcpu->kvm, &intids);
> + if (nr_irqs < 0)
> + return nr_irqs;
> +
> + for (i = 0; i < nr_irqs; i++) {
> + int byte_offset, bit_nr;
> +
> + byte_offset = intids[i] / BITS_PER_BYTE;
> + bit_nr = intids[i] % BITS_PER_BYTE;
> +
> + ret = kvm_read_guest(vcpu->kvm, pendbase + byte_offset,
> + &pendmask, 1);
How about having a small cache of the last read offset and data? If LPIs
are contiguously allocated, you save yourself quite a few (expensive)
userspace accesses.
> + if (ret) {
> + kfree(intids);
> + return ret;
> + }
> +
> + irq = vgic_get_irq(vcpu->kvm, NULL, intids[i]);
> + spin_lock(&irq->irq_lock);
> + irq->pending = pendmask & (1U << bit_nr);
> + vgic_queue_irq_unlock(vcpu->kvm, irq);
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +
> + return ret;
> +}
>
> static unsigned long vgic_mmio_read_its_ctlr(struct kvm *vcpu,
> struct vgic_its *its,
> @@ -415,6 +490,12 @@ static struct vgic_register_region its_registers[] = {
> VGIC_ACCESS_32bit),
> };
>
> +/* This is called on setting the LPI enable bit in the redistributor. */
> +void vgic_enable_lpis(struct kvm_vcpu *vcpu)
> +{
> + its_sync_lpi_pending_table(vcpu);
> +}
> +
> static int vgic_its_register(struct kvm *kvm, struct vgic_its *its)
> {
> struct vgic_io_device *iodev = &its->iodev;
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index eef9ec1..4a9165f 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -25,6 +25,7 @@
> #define IS_VGIC_ADDR_UNDEF(_x) ((_x) == VGIC_ADDR_UNDEF)
>
> #define INTERRUPT_ID_BITS_SPIS 10
> +#define INTERRUPT_ID_BITS_ITS 16
Do we have plan for a userspace-accessible property for this? I can
imagine userspace willing to have bigger LPI space...
> #define VGIC_PRI_BITS 5
>
> #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
> @@ -79,6 +80,7 @@ int vgic_register_redist_iodevs(struct kvm *kvm, gpa_t dist_base_address);
> bool vgic_has_its(struct kvm *kvm);
> int kvm_vgic_register_its_device(void);
> struct vgic_irq *vgic_its_get_lpi(struct kvm *kvm, u32 intid);
> +void vgic_enable_lpis(struct kvm_vcpu *vcpu);
> #else
> static inline void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu)
> {
> @@ -145,6 +147,10 @@ static inline struct vgic_irq *vgic_its_get_lpi(struct kvm *kvm, u32 intid)
> {
> return NULL;
> }
> +
> +static inline void vgic_enable_lpis(struct kvm_vcpu *vcpu)
> +{
> +}
> #endif
>
> int kvm_register_vgic_device(unsigned long type);
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 13/17] KVM: arm64: read initial LPI pending table
Date: Mon, 11 Jul 2016 17:50:47 +0100 [thread overview]
Message-ID: <5783CE67.2070202@arm.com> (raw)
In-Reply-To: <20160705112309.28877-14-andre.przywara@arm.com>
On 05/07/16 12:23, Andre Przywara wrote:
> The LPI pending status for a GICv3 redistributor is held in a table
> in (guest) memory. To achieve reasonable performance, we cache this
> data in our struct vgic_irq. The initial pending state must be read
> from guest memory upon enabling LPIs for this redistributor.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 81 ++++++++++++++++++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic.h | 6 ++++
> 2 files changed, 87 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index 1e2e649..29bb4fe 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -93,6 +93,81 @@ struct its_itte {
> list_for_each_entry(itte, &(dev)->itt_head, itte_list)
>
> #define CBASER_ADDRESS(x) ((x) & GENMASK_ULL(51, 12))
> +#define PENDBASER_ADDRESS(x) ((x) & GENMASK_ULL(51, 16))
52 bits again. Pick a side!
> +
> +static int vgic_its_copy_lpi_list(struct kvm *kvm, u32 **intid_ptr)
> +{
> + struct vgic_dist *dist = &kvm->arch.vgic;
> + struct vgic_irq *irq;
> + u32 *intids;
> + int irq_count = dist->lpi_list_count, i = 0;
> +
> + /*
> + * We use the current value of the list length, which may change
> + * after the kmalloc. We don't care, because the guest shouldn't
> + * change anything while the command handling is still running,
> + * and in the worst case we would miss a new IRQ, which one wouldn't
> + * expect to be covered by this command anyway.
> + */
> + intids = kmalloc_array(irq_count, sizeof(intids[0]), GFP_KERNEL);
> + if (!intids)
> + return -ENOMEM;
> +
> + spin_lock(&dist->lpi_list_lock);
> + list_for_each_entry(irq, &dist->lpi_list_head, lpi_entry) {
> + if (kref_get_unless_zero(&irq->refcount)) {
> + intids[i] = irq->intid;
> + vgic_put_irq_locked(kvm, irq);
This is ugly. You know you're not going to free the irq, since it was at
least one when you did kref_get_unless_zero(). Why not doing a simple
kref_put (possibly in a macro so that you can hide the dummy release
function)?
> + }
> + if (i++ == irq_count)
> + break;
> + }
> + spin_unlock(&dist->lpi_list_lock);
> +
> + *intid_ptr = intids;
> + return irq_count;
> +}
> +
> +/*
> + * Scan the whole LPI pending table and sync the pending bit in there
> + * with our own data structures. This relies on the LPI being
> + * mapped before.
> + */
> +static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
> +{
> + gpa_t pendbase = PENDBASER_ADDRESS(vcpu->arch.vgic_cpu.pendbaser);
> + struct vgic_irq *irq;
> + u8 pendmask;
> + int ret = 0;
> + u32 *intids;
> + int nr_irqs, i;
> +
> + nr_irqs = vgic_its_copy_lpi_list(vcpu->kvm, &intids);
> + if (nr_irqs < 0)
> + return nr_irqs;
> +
> + for (i = 0; i < nr_irqs; i++) {
> + int byte_offset, bit_nr;
> +
> + byte_offset = intids[i] / BITS_PER_BYTE;
> + bit_nr = intids[i] % BITS_PER_BYTE;
> +
> + ret = kvm_read_guest(vcpu->kvm, pendbase + byte_offset,
> + &pendmask, 1);
How about having a small cache of the last read offset and data? If LPIs
are contiguously allocated, you save yourself quite a few (expensive)
userspace accesses.
> + if (ret) {
> + kfree(intids);
> + return ret;
> + }
> +
> + irq = vgic_get_irq(vcpu->kvm, NULL, intids[i]);
> + spin_lock(&irq->irq_lock);
> + irq->pending = pendmask & (1U << bit_nr);
> + vgic_queue_irq_unlock(vcpu->kvm, irq);
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +
> + return ret;
> +}
>
> static unsigned long vgic_mmio_read_its_ctlr(struct kvm *vcpu,
> struct vgic_its *its,
> @@ -415,6 +490,12 @@ static struct vgic_register_region its_registers[] = {
> VGIC_ACCESS_32bit),
> };
>
> +/* This is called on setting the LPI enable bit in the redistributor. */
> +void vgic_enable_lpis(struct kvm_vcpu *vcpu)
> +{
> + its_sync_lpi_pending_table(vcpu);
> +}
> +
> static int vgic_its_register(struct kvm *kvm, struct vgic_its *its)
> {
> struct vgic_io_device *iodev = &its->iodev;
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index eef9ec1..4a9165f 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -25,6 +25,7 @@
> #define IS_VGIC_ADDR_UNDEF(_x) ((_x) == VGIC_ADDR_UNDEF)
>
> #define INTERRUPT_ID_BITS_SPIS 10
> +#define INTERRUPT_ID_BITS_ITS 16
Do we have plan for a userspace-accessible property for this? I can
imagine userspace willing to have bigger LPI space...
> #define VGIC_PRI_BITS 5
>
> #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
> @@ -79,6 +80,7 @@ int vgic_register_redist_iodevs(struct kvm *kvm, gpa_t dist_base_address);
> bool vgic_has_its(struct kvm *kvm);
> int kvm_vgic_register_its_device(void);
> struct vgic_irq *vgic_its_get_lpi(struct kvm *kvm, u32 intid);
> +void vgic_enable_lpis(struct kvm_vcpu *vcpu);
> #else
> static inline void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu)
> {
> @@ -145,6 +147,10 @@ static inline struct vgic_irq *vgic_its_get_lpi(struct kvm *kvm, u32 intid)
> {
> return NULL;
> }
> +
> +static inline void vgic_enable_lpis(struct kvm_vcpu *vcpu)
> +{
> +}
> #endif
>
> int kvm_register_vgic_device(unsigned long type);
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2016-07-11 16:50 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 11:22 [PATCH v8 00/17] KVM: arm64: GICv3 ITS emulation Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-05 11:22 ` [PATCH v8 01/17] KVM: arm/arm64: move redistributor kvm_io_devices Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-05 11:22 ` [PATCH v8 02/17] KVM: arm/arm64: check return value for kvm_register_vgic_device Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-05 11:22 ` [PATCH v8 03/17] KVM: extend struct kvm_msi to hold a 32-bit device ID Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-06 21:06 ` Christoffer Dall
2016-07-06 21:06 ` Christoffer Dall
2016-07-06 21:54 ` André Przywara
2016-07-06 21:54 ` André Przywara
2016-07-07 9:37 ` Christoffer Dall
2016-07-07 9:37 ` Christoffer Dall
2016-07-05 11:22 ` [PATCH v8 04/17] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-05 11:22 ` [PATCH v8 05/17] KVM: kvm_io_bus: add kvm_io_bus_get_dev() call Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-06 21:15 ` Christoffer Dall
2016-07-06 21:15 ` Christoffer Dall
2016-07-06 21:36 ` André Przywara
2016-07-06 21:36 ` André Przywara
2016-07-05 11:22 ` [PATCH v8 06/17] KVM: arm/arm64: VGIC: add refcounting for IRQs Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-07 13:13 ` Christoffer Dall
2016-07-07 13:13 ` Christoffer Dall
2016-07-07 15:00 ` Marc Zyngier
2016-07-07 15:00 ` Marc Zyngier
2016-07-08 10:28 ` Andre Przywara
2016-07-08 10:28 ` Andre Przywara
2016-07-08 10:50 ` Marc Zyngier
2016-07-08 10:50 ` Marc Zyngier
2016-07-08 12:54 ` André Przywara
2016-07-08 12:54 ` André Przywara
2016-07-08 13:09 ` Marc Zyngier
2016-07-08 13:09 ` Marc Zyngier
2016-07-08 13:14 ` André Przywara
2016-07-08 13:14 ` André Przywara
2016-07-05 11:22 ` [PATCH v8 07/17] irqchip: refactor and add GICv3 definitions Andre Przywara
2016-07-05 11:22 ` Andre Przywara
2016-07-05 11:23 ` [PATCH v8 08/17] KVM: arm64: handle ITS related GICv3 redistributor registers Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-08 15:40 ` Christoffer Dall
2016-07-08 15:40 ` Christoffer Dall
2016-07-11 7:45 ` André Przywara
2016-07-11 7:45 ` André Przywara
2016-07-05 11:23 ` [PATCH v8 09/17] KVM: arm64: introduce ITS emulation file with MMIO framework Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-08 13:34 ` Marc Zyngier
2016-07-08 13:34 ` Marc Zyngier
2016-07-08 13:55 ` Marc Zyngier
2016-07-08 13:55 ` Marc Zyngier
2016-07-08 14:04 ` André Przywara
2016-07-08 14:04 ` André Przywara
2016-07-05 11:23 ` [PATCH v8 10/17] KVM: arm64: introduce new KVM ITS device Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-05 11:23 ` [PATCH v8 11/17] KVM: arm64: implement basic ITS register handlers Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-08 14:58 ` Marc Zyngier
2016-07-08 14:58 ` Marc Zyngier
2016-07-11 9:00 ` Andre Przywara
2016-07-11 9:00 ` Andre Przywara
2016-07-11 14:21 ` Marc Zyngier
2016-07-11 14:21 ` Marc Zyngier
2016-07-05 11:23 ` [PATCH v8 12/17] KVM: arm64: connect LPIs to the VGIC emulation Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-11 16:20 ` Marc Zyngier
2016-07-11 16:20 ` Marc Zyngier
2016-07-05 11:23 ` [PATCH v8 13/17] KVM: arm64: read initial LPI pending table Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-11 16:50 ` Marc Zyngier [this message]
2016-07-11 16:50 ` Marc Zyngier
2016-07-11 17:38 ` Andre Przywara
2016-07-11 17:38 ` Andre Przywara
2016-07-12 11:33 ` Andre Przywara
2016-07-12 11:33 ` Andre Przywara
2016-07-12 12:39 ` Marc Zyngier
2016-07-12 12:39 ` Marc Zyngier
2016-07-05 11:23 ` [PATCH v8 14/17] KVM: arm64: allow updates of LPI configuration table Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-11 16:59 ` Marc Zyngier
2016-07-11 16:59 ` Marc Zyngier
2016-07-05 11:23 ` [PATCH v8 15/17] KVM: arm64: implement ITS command queue command handlers Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-11 17:17 ` Marc Zyngier
2016-07-11 17:17 ` Marc Zyngier
2016-07-11 17:47 ` Andre Przywara
2016-07-11 17:47 ` Andre Przywara
2016-07-11 17:52 ` Marc Zyngier
2016-07-11 17:52 ` Marc Zyngier
2016-07-05 11:23 ` [PATCH v8 16/17] KVM: arm64: implement MSI injection in ITS emulation Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-05 11:23 ` [PATCH v8 17/17] KVM: arm64: enable ITS emulation as a virtual MSI controller Andre Przywara
2016-07-05 11:23 ` Andre Przywara
2016-07-06 8:52 ` [PATCH v8 00/17] KVM: arm64: GICv3 ITS emulation Auger Eric
2016-07-06 8:52 ` Auger Eric
2016-07-11 17:36 ` Marc Zyngier
2016-07-11 17:36 ` Marc Zyngier
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=5783CE67.2070202@arm.com \
--to=marc.zyngier@arm.com \
--cc=andre.przywara@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.