From: Christoffer Dall <christoffer.dall@linaro.org>
To: Eric Auger <eric.auger@redhat.com>
Cc: kvm@vger.kernel.org, Prasun.Kapoor@cavium.com,
marc.zyngier@arm.com, andre.przywara@arm.com,
quintela@redhat.com, dgilbert@redhat.com,
bjsprakash.linux@gmail.com, Vijaya.Kumar@cavium.com,
vijayak@caviumnetworks.com, pbonzini@redhat.com,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, eric.auger.pro@gmail.com
Subject: Re: [PATCH v6 15/24] KVM: arm64: vgic-its: Read config and pending bit in add_lpi()
Date: Fri, 5 May 2017 02:57:08 -0700 [thread overview]
Message-ID: <20170505095708.GB1419@lvm> (raw)
In-Reply-To: <1493898284-29504-16-git-send-email-eric.auger@redhat.com>
On Thu, May 04, 2017 at 01:44:35PM +0200, Eric Auger wrote:
> When creating the lpi we now ask the redistributor what is the state
> of the LPI (priority, enabled, pending).
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> v6: creation
> ---
> virt/kvm/arm/vgic/vgic-its.c | 35 ++++++++++++++++++++++++-----------
> 1 file changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index f43ea30c..3ad615a 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -38,6 +38,8 @@
>
> static int vgic_its_set_abi(struct vgic_its *its, int rev);
> static const struct vgic_its_abi *vgic_its_get_abi(struct vgic_its *its);
> +static int update_lpi_config(struct kvm *kvm, struct vgic_irq *irq,
> + struct kvm_vcpu *filter_vcpu);
>
> /*
> * Creates a new (reference to a) struct vgic_irq for a given LPI.
> @@ -46,10 +48,12 @@ static const struct vgic_its_abi *vgic_its_get_abi(struct vgic_its *its);
> * If this is a "new" LPI, we allocate and initialize a new struct vgic_irq.
> * This function returns a pointer to the _unlocked_ structure.
> */
> -static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid)
> +static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid,
> + struct kvm_vcpu *vcpu)
> {
> struct vgic_dist *dist = &kvm->arch.vgic;
> struct vgic_irq *irq = vgic_get_irq(kvm, NULL, intid), *oldirq;
> + int ret;
>
> /* In this case there is no put, since we keep the reference. */
> if (irq)
> @@ -66,6 +70,7 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid)
> irq->config = VGIC_CONFIG_EDGE;
> kref_init(&irq->refcount);
> irq->intid = intid;
> + irq->target_vcpu = vcpu;
>
> spin_lock(&dist->lpi_list_lock);
>
> @@ -97,6 +102,19 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid)
> out_unlock:
> spin_unlock(&dist->lpi_list_lock);
>
> + /*
> + * We "cache" the configuration table entries in out struct vgic_irq's.
s/out/our/ ?
> + * However we only have those structs for mapped IRQs, so we read in
> + * the respective config data from memory here upon mapping the LPI.
> + */
> + ret = update_lpi_config(kvm, irq, NULL);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
> + if (ret)
> + return ERR_PTR(ret);
> +
> return irq;
> }
>
> @@ -769,6 +787,7 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
> u32 event_id = its_cmd_get_id(its_cmd);
> u32 coll_id = its_cmd_get_collection(its_cmd);
> struct its_ite *ite;
> + struct kvm_vcpu *vcpu = NULL;
> struct its_device *device;
> struct its_collection *collection, *new_coll = NULL;
> int lpi_nr;
> @@ -814,7 +833,10 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
> ite->collection = collection;
> ite->lpi = lpi_nr;
>
> - irq = vgic_add_lpi(kvm, lpi_nr);
> + if (its_is_collection_mapped(collection))
> + vcpu = kvm_get_vcpu(kvm, collection->target_addr);
> +
> + irq = vgic_add_lpi(kvm, lpi_nr, vcpu);
So, if we don't have the collection and therefore end up with irq->vcpu
== NULL, how do we ever read the pending bit from memory as the affinity
may later change?
Is this a problem with our idea of only looking at the pending bit on
vgic_add_lpi, or does it just mean that we should sample the pending bit
whenever we move LPIs around to VCPUs and if the bit is set, then also
set the pennding_latch (if not already set), or what should happen here?
I think in any case, we should have a comment here explaining that vcpu
configuration data gets picked up later?
Thanks,
-Christoffer
> if (IS_ERR(irq)) {
> if (new_coll)
> vgic_its_free_collection(its, coll_id);
> @@ -823,15 +845,6 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
> }
> ite->irq = irq;
>
> - update_affinity_ite(kvm, ite);
> -
> - /*
> - * We "cache" the configuration table entries in out struct vgic_irq's.
> - * However we only have those structs for mapped IRQs, so we read in
> - * the respective config data from memory here upon mapping the LPI.
> - */
> - update_lpi_config(kvm, ite->irq, NULL);
> -
> return 0;
> }
>
> --
> 2.5.5
>
WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 15/24] KVM: arm64: vgic-its: Read config and pending bit in add_lpi()
Date: Fri, 5 May 2017 02:57:08 -0700 [thread overview]
Message-ID: <20170505095708.GB1419@lvm> (raw)
In-Reply-To: <1493898284-29504-16-git-send-email-eric.auger@redhat.com>
On Thu, May 04, 2017 at 01:44:35PM +0200, Eric Auger wrote:
> When creating the lpi we now ask the redistributor what is the state
> of the LPI (priority, enabled, pending).
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> v6: creation
> ---
> virt/kvm/arm/vgic/vgic-its.c | 35 ++++++++++++++++++++++++-----------
> 1 file changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index f43ea30c..3ad615a 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -38,6 +38,8 @@
>
> static int vgic_its_set_abi(struct vgic_its *its, int rev);
> static const struct vgic_its_abi *vgic_its_get_abi(struct vgic_its *its);
> +static int update_lpi_config(struct kvm *kvm, struct vgic_irq *irq,
> + struct kvm_vcpu *filter_vcpu);
>
> /*
> * Creates a new (reference to a) struct vgic_irq for a given LPI.
> @@ -46,10 +48,12 @@ static const struct vgic_its_abi *vgic_its_get_abi(struct vgic_its *its);
> * If this is a "new" LPI, we allocate and initialize a new struct vgic_irq.
> * This function returns a pointer to the _unlocked_ structure.
> */
> -static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid)
> +static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid,
> + struct kvm_vcpu *vcpu)
> {
> struct vgic_dist *dist = &kvm->arch.vgic;
> struct vgic_irq *irq = vgic_get_irq(kvm, NULL, intid), *oldirq;
> + int ret;
>
> /* In this case there is no put, since we keep the reference. */
> if (irq)
> @@ -66,6 +70,7 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid)
> irq->config = VGIC_CONFIG_EDGE;
> kref_init(&irq->refcount);
> irq->intid = intid;
> + irq->target_vcpu = vcpu;
>
> spin_lock(&dist->lpi_list_lock);
>
> @@ -97,6 +102,19 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid)
> out_unlock:
> spin_unlock(&dist->lpi_list_lock);
>
> + /*
> + * We "cache" the configuration table entries in out struct vgic_irq's.
s/out/our/ ?
> + * However we only have those structs for mapped IRQs, so we read in
> + * the respective config data from memory here upon mapping the LPI.
> + */
> + ret = update_lpi_config(kvm, irq, NULL);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
> + if (ret)
> + return ERR_PTR(ret);
> +
> return irq;
> }
>
> @@ -769,6 +787,7 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
> u32 event_id = its_cmd_get_id(its_cmd);
> u32 coll_id = its_cmd_get_collection(its_cmd);
> struct its_ite *ite;
> + struct kvm_vcpu *vcpu = NULL;
> struct its_device *device;
> struct its_collection *collection, *new_coll = NULL;
> int lpi_nr;
> @@ -814,7 +833,10 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
> ite->collection = collection;
> ite->lpi = lpi_nr;
>
> - irq = vgic_add_lpi(kvm, lpi_nr);
> + if (its_is_collection_mapped(collection))
> + vcpu = kvm_get_vcpu(kvm, collection->target_addr);
> +
> + irq = vgic_add_lpi(kvm, lpi_nr, vcpu);
So, if we don't have the collection and therefore end up with irq->vcpu
== NULL, how do we ever read the pending bit from memory as the affinity
may later change?
Is this a problem with our idea of only looking at the pending bit on
vgic_add_lpi, or does it just mean that we should sample the pending bit
whenever we move LPIs around to VCPUs and if the bit is set, then also
set the pennding_latch (if not already set), or what should happen here?
I think in any case, we should have a comment here explaining that vcpu
configuration data gets picked up later?
Thanks,
-Christoffer
> if (IS_ERR(irq)) {
> if (new_coll)
> vgic_its_free_collection(its, coll_id);
> @@ -823,15 +845,6 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,
> }
> ite->irq = irq;
>
> - update_affinity_ite(kvm, ite);
> -
> - /*
> - * We "cache" the configuration table entries in out struct vgic_irq's.
> - * However we only have those structs for mapped IRQs, so we read in
> - * the respective config data from memory here upon mapping the LPI.
> - */
> - update_lpi_config(kvm, ite->irq, NULL);
> -
> return 0;
> }
>
> --
> 2.5.5
>
next prev parent reply other threads:[~2017-05-05 9:54 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 11:44 [PATCH v6 00/24] vITS save/restore Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 11:44 ` [PATCH v6 01/24] KVM: arm/arm64: Add ITS save/restore API documentation Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 13:23 ` Christoffer Dall
2017-05-04 13:23 ` Christoffer Dall
2017-05-04 14:50 ` Auger Eric
2017-05-04 14:50 ` Auger Eric
2017-05-04 16:52 ` Christoffer Dall
2017-05-04 16:52 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 02/24] KVM: arm/arm64: Add GICV3 pending table save " Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 13:24 ` Christoffer Dall
2017-05-04 13:24 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 03/24] KVM: arm/arm64: vgic-its: rename itte into ite Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 11:44 ` [PATCH v6 04/24] arm/arm64: vgic: turn vgic_find_mmio_region into public Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 11:44 ` [PATCH v6 05/24] KVM: arm64: vgic-its: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 11:44 ` [PATCH v6 06/24] KVM: arm/arm64: vgic: expose (un)lock_all_vcpus Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 11:44 ` [PATCH v6 07/24] KVM: arm64: vgic-its: Implement vgic_its_has_attr_regs and attr_regs_access Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 14:04 ` Marc Zyngier
2017-05-04 14:04 ` Marc Zyngier
2017-05-04 15:03 ` Auger Eric
2017-05-04 15:03 ` Auger Eric
2017-05-04 16:48 ` Christoffer Dall
2017-05-04 16:48 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 08/24] KVM: arm64: vgic-its: Implement vgic_mmio_uaccess_write_its_creadr Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 14:16 ` Marc Zyngier
2017-05-04 14:16 ` Marc Zyngier
2017-05-04 15:09 ` Auger Eric
2017-05-04 15:09 ` Auger Eric
2017-05-04 17:09 ` Christoffer Dall
2017-05-04 17:09 ` Christoffer Dall
2017-05-05 8:06 ` Auger Eric
2017-05-05 8:06 ` Auger Eric
2017-05-04 11:44 ` [PATCH v6 09/24] KVM: arm64: vgic-its: Introduce migration ABI infrastructure Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 14:45 ` Marc Zyngier
2017-05-04 14:45 ` Marc Zyngier
2017-05-04 17:13 ` Christoffer Dall
2017-05-04 17:13 ` Christoffer Dall
2017-05-05 8:16 ` Auger Eric
2017-05-05 8:16 ` Auger Eric
2017-05-05 9:43 ` Christoffer Dall
2017-05-05 9:43 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 10/24] KVM: arm64: vgic-its: Implement vgic_mmio_uaccess_write_its_iidr Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 15:39 ` Marc Zyngier
2017-05-04 15:39 ` Marc Zyngier
2017-05-04 17:14 ` Christoffer Dall
2017-05-04 17:14 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 11/24] KVM: arm64: vgic-its: Interpret MAPD Size field and check related errors Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 9:44 ` Marc Zyngier
2017-05-05 9:44 ` Marc Zyngier
2017-05-04 11:44 ` [PATCH v6 12/24] KVM: arm64: vgic-its: Interpret MAPD ITT_addr field Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 17:16 ` Christoffer Dall
2017-05-04 17:16 ` Christoffer Dall
2017-05-05 9:45 ` Marc Zyngier
2017-05-05 9:45 ` Marc Zyngier
2017-05-04 11:44 ` [PATCH v6 13/24] KVM: arm64: vgic-its: Check the device id matches TYPER DEVBITS range Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 17:19 ` Christoffer Dall
2017-05-04 17:19 ` Christoffer Dall
2017-05-04 17:23 ` Marc Zyngier
2017-05-04 17:23 ` Marc Zyngier
2017-05-04 11:44 ` [PATCH v6 14/24] KVM: arm64: vgic-v3: vgic_v3_lpi_sync_pending_status Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 8:11 ` Christoffer Dall
2017-05-05 8:11 ` Christoffer Dall
2017-05-05 9:45 ` Auger Eric
2017-05-05 9:45 ` Auger Eric
2017-05-05 9:59 ` Marc Zyngier
2017-05-05 9:59 ` Marc Zyngier
2017-05-05 10:10 ` Christoffer Dall
2017-05-05 10:10 ` Christoffer Dall
2017-05-05 10:35 ` Marc Zyngier
2017-05-05 10:35 ` Marc Zyngier
2017-05-05 14:20 ` Auger Eric
2017-05-05 14:20 ` Auger Eric
2017-05-05 14:50 ` Christoffer Dall
2017-05-05 14:50 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 15/24] KVM: arm64: vgic-its: Read config and pending bit in add_lpi() Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 9:57 ` Christoffer Dall [this message]
2017-05-05 9:57 ` Christoffer Dall
2017-05-05 12:50 ` Marc Zyngier
2017-05-05 12:50 ` Marc Zyngier
2017-05-05 14:50 ` Auger Eric
2017-05-05 14:50 ` Auger Eric
2017-05-05 18:07 ` Christoffer Dall
2017-05-05 18:07 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 16/24] KVM: arm64: vgic-its: KVM_DEV_ARM_ITS_SAVE/RESTORE_TABLES Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 11:55 ` Christoffer Dall
2017-05-05 11:55 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 17/24] KVM: arm64: vgic-its: vgic_its_alloc_ite/device Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 12:04 ` Christoffer Dall
2017-05-05 12:04 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 18/24] KVM: arm64: vgic-its: Add infrastructure for table lookup Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 12:16 ` Christoffer Dall
2017-05-05 12:16 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 19/24] KVM: arm64: vgic-its: Collection table save/restore Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 12:28 ` Christoffer Dall
2017-05-05 12:28 ` Christoffer Dall
2017-05-05 14:28 ` Auger Eric
2017-05-05 14:28 ` Auger Eric
2017-05-05 14:43 ` Auger Eric
2017-05-05 14:43 ` Auger Eric
2017-05-04 11:44 ` [PATCH v6 20/24] KVM: arm64: vgic-its: vgic_its_check_id returns the entry's GPA Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-04 11:44 ` [PATCH v6 21/24] KVM: arm64: vgic-its: Device table save/restore Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 12:44 ` Christoffer Dall
2017-05-05 12:44 ` Christoffer Dall
2017-05-05 16:23 ` Auger Eric
2017-05-05 16:23 ` Auger Eric
2017-05-05 18:12 ` Christoffer Dall
2017-05-05 18:12 ` Christoffer Dall
2017-05-06 10:21 ` Auger Eric
2017-05-06 10:21 ` Auger Eric
2017-05-04 11:44 ` [PATCH v6 22/24] KVM: arm64: vgic-its: ITT save and restore Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 14:50 ` Christoffer Dall
2017-05-05 14:50 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 23/24] KVM: arm64: vgic-its: Fix pending table sync Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 14:54 ` Christoffer Dall
2017-05-05 14:54 ` Christoffer Dall
2017-05-04 11:44 ` [PATCH v6 24/24] KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES Eric Auger
2017-05-04 11:44 ` Eric Auger
2017-05-05 9:24 ` Auger Eric
2017-05-05 9:24 ` Auger Eric
2017-05-05 14:56 ` Christoffer Dall
2017-05-05 14:56 ` Christoffer Dall
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=20170505095708.GB1419@lvm \
--to=christoffer.dall@linaro.org \
--cc=Prasun.Kapoor@cavium.com \
--cc=Vijaya.Kumar@cavium.com \
--cc=andre.przywara@arm.com \
--cc=bjsprakash.linux@gmail.com \
--cc=dgilbert@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=pbonzini@redhat.com \
--cc=quintela@redhat.com \
--cc=vijayak@caviumnetworks.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 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.