From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: Andre Przywara <andre.przywara@arm.com>,
kernel-team@android.com, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 2/4] KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation
Date: Wed, 16 Mar 2022 09:31:48 +0000 [thread overview]
Message-ID: <87bky6z1iz.wl-maz@kernel.org> (raw)
In-Reply-To: <YjF07lltAEn6X22V@google.com>
On Wed, 16 Mar 2022 05:26:06 +0000,
Oliver Upton <oupton@google.com> wrote:
>
> Hi Marc,
>
> On Mon, Mar 14, 2022 at 04:40:42PM +0000, Marc Zyngier wrote:
> > Since GICv4.1, it has become legal for an implementation to advertise
> > GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more
> > efficient invalidation scheme (no guest command queue contention when
> > multiple CPUs are generating invalidations).
> >
> > Provide the invalidation registers as a primitive to their ITS
> > counterpart. Note that we don't advertise them to the guest yet
> > (the architecture allows an implementation to do this).
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/vgic/vgic-its.c | 62 ++++++++++++++++++++----------
> > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 62 ++++++++++++++++++++++++++++++
> > arch/arm64/kvm/vgic/vgic.h | 4 ++
> > include/kvm/arm_vgic.h | 1 +
> > 4 files changed, 108 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
> > index 089fc2ffcb43..cc62d8a8180f 100644
> > --- a/arch/arm64/kvm/vgic/vgic-its.c
> > +++ b/arch/arm64/kvm/vgic/vgic-its.c
> > @@ -1272,6 +1272,11 @@ static int vgic_its_cmd_handle_clear(struct kvm *kvm, struct vgic_its *its,
> > return 0;
> > }
> >
> > +int vgic_its_inv_lpi(struct kvm *kvm, struct vgic_irq *irq)
> > +{
> > + return update_lpi_config(kvm, irq, NULL, true);
> > +}
> > +
> > /*
> > * The INV command syncs the configuration bits from the memory table.
> > * Must be called with the its_lock mutex held.
> > @@ -1288,7 +1293,41 @@ static int vgic_its_cmd_handle_inv(struct kvm *kvm, struct vgic_its *its,
> > if (!ite)
> > return E_ITS_INV_UNMAPPED_INTERRUPT;
> >
> > - return update_lpi_config(kvm, ite->irq, NULL, true);
> > + return vgic_its_inv_lpi(kvm, ite->irq);
> > +}
> > +
> > +/**
> > + * vgic_its_invall - invalidate all LPIs targetting a given vcpu
> > + * @vcpu: the vcpu for which the RD is targetted by an invalidation
> > + *
> > + * Contrary to the INVALL command, this targets a RD instead of a
> > + * collection, and we don't need to hold the its_lock, since no ITS is
> > + * involved here.
> > + */
> > +int vgic_its_invall(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm *kvm = vcpu->kvm;
> > + int irq_count, i = 0;
> > + u32 *intids;
> > +
> > + irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids);
> > + if (irq_count < 0)
> > + return irq_count;
> > +
> > + for (i = 0; i < irq_count; i++) {
> > + struct vgic_irq *irq = vgic_get_irq(kvm, NULL, intids[i]);
> > + if (!irq)
> > + continue;
> > + update_lpi_config(kvm, irq, vcpu, false);
> > + vgic_put_irq(kvm, irq);
> > + }
> > +
> > + kfree(intids);
> > +
> > + if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm)
> > + its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe);
> > +
> > + return 0;
> > }
>
> nit: the refactoring happening at the same time as the functional change
> is a bit distracting. Looks fine though.
Yeah, it didn't seem to warrant an extra patch, given that we're
really only moving things about.
>
> > /*
> > @@ -1305,32 +1344,13 @@ static int vgic_its_cmd_handle_invall(struct kvm *kvm, struct vgic_its *its,
> > u32 coll_id = its_cmd_get_collection(its_cmd);
> > struct its_collection *collection;
> > struct kvm_vcpu *vcpu;
> > - struct vgic_irq *irq;
> > - u32 *intids;
> > - int irq_count, i;
> >
> > collection = find_collection(its, coll_id);
> > if (!its_is_collection_mapped(collection))
> > return E_ITS_INVALL_UNMAPPED_COLLECTION;
> >
> > vcpu = kvm_get_vcpu(kvm, collection->target_addr);
> > -
> > - irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids);
> > - if (irq_count < 0)
> > - return irq_count;
> > -
> > - for (i = 0; i < irq_count; i++) {
> > - irq = vgic_get_irq(kvm, NULL, intids[i]);
> > - if (!irq)
> > - continue;
> > - update_lpi_config(kvm, irq, vcpu, false);
> > - vgic_put_irq(kvm, irq);
> > - }
> > -
> > - kfree(intids);
> > -
> > - if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm)
> > - its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe);
> > + vgic_its_invall(vcpu);
> >
> > return 0;
> > }
> > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > index 58e40b4874f8..186bf35078bf 100644
> > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > @@ -525,6 +525,59 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> > pendbaser) != old_pendbaser);
> > }
> >
> > +static unsigned long vgic_mmio_read_sync(struct kvm_vcpu *vcpu,
> > + gpa_t addr, unsigned int len)
> > +{
> > + return !!atomic_read(&vcpu->arch.vgic_cpu.syncr_busy);
> > +}
> > +
> > +static void vgic_make_rdist_busy(struct kvm_vcpu *vcpu, bool busy)
>
> nit: s/make/set, since you use this helper to decrement the counter too.
Sure, works for me.
> > +{
> > + if (busy) {
> > + atomic_inc(&vcpu->arch.vgic_cpu.syncr_busy);
> > + smp_mb__after_atomic();
> > + } else {
> > + smp_mb__before_atomic();
> > + atomic_dec(&vcpu->arch.vgic_cpu.syncr_busy);
> > + }
> > +}
> > +
> > +static void vgic_mmio_write_invlpi(struct kvm_vcpu *vcpu,
> > + gpa_t addr, unsigned int len,
> > + unsigned long val)
> > +{
> > + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> > + struct vgic_irq *irq;
> > +
> > + if (!vgic_cpu->lpis_enabled)
> > + return;
> > +
> > + vgic_make_rdist_busy(vcpu, true);
> > +
> > + irq = vgic_get_irq(vcpu->kvm, NULL, val);
> > + if (!irq)
> > + return;
>
> Isn't the busy counter unbalanced if you return early?
Huh, well caught. Fix incoming.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
kvmarm@lists.cs.columbia.edu, kernel-team@android.com,
Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH 2/4] KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation
Date: Wed, 16 Mar 2022 09:31:48 +0000 [thread overview]
Message-ID: <87bky6z1iz.wl-maz@kernel.org> (raw)
In-Reply-To: <YjF07lltAEn6X22V@google.com>
On Wed, 16 Mar 2022 05:26:06 +0000,
Oliver Upton <oupton@google.com> wrote:
>
> Hi Marc,
>
> On Mon, Mar 14, 2022 at 04:40:42PM +0000, Marc Zyngier wrote:
> > Since GICv4.1, it has become legal for an implementation to advertise
> > GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more
> > efficient invalidation scheme (no guest command queue contention when
> > multiple CPUs are generating invalidations).
> >
> > Provide the invalidation registers as a primitive to their ITS
> > counterpart. Note that we don't advertise them to the guest yet
> > (the architecture allows an implementation to do this).
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/vgic/vgic-its.c | 62 ++++++++++++++++++++----------
> > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 62 ++++++++++++++++++++++++++++++
> > arch/arm64/kvm/vgic/vgic.h | 4 ++
> > include/kvm/arm_vgic.h | 1 +
> > 4 files changed, 108 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
> > index 089fc2ffcb43..cc62d8a8180f 100644
> > --- a/arch/arm64/kvm/vgic/vgic-its.c
> > +++ b/arch/arm64/kvm/vgic/vgic-its.c
> > @@ -1272,6 +1272,11 @@ static int vgic_its_cmd_handle_clear(struct kvm *kvm, struct vgic_its *its,
> > return 0;
> > }
> >
> > +int vgic_its_inv_lpi(struct kvm *kvm, struct vgic_irq *irq)
> > +{
> > + return update_lpi_config(kvm, irq, NULL, true);
> > +}
> > +
> > /*
> > * The INV command syncs the configuration bits from the memory table.
> > * Must be called with the its_lock mutex held.
> > @@ -1288,7 +1293,41 @@ static int vgic_its_cmd_handle_inv(struct kvm *kvm, struct vgic_its *its,
> > if (!ite)
> > return E_ITS_INV_UNMAPPED_INTERRUPT;
> >
> > - return update_lpi_config(kvm, ite->irq, NULL, true);
> > + return vgic_its_inv_lpi(kvm, ite->irq);
> > +}
> > +
> > +/**
> > + * vgic_its_invall - invalidate all LPIs targetting a given vcpu
> > + * @vcpu: the vcpu for which the RD is targetted by an invalidation
> > + *
> > + * Contrary to the INVALL command, this targets a RD instead of a
> > + * collection, and we don't need to hold the its_lock, since no ITS is
> > + * involved here.
> > + */
> > +int vgic_its_invall(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm *kvm = vcpu->kvm;
> > + int irq_count, i = 0;
> > + u32 *intids;
> > +
> > + irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids);
> > + if (irq_count < 0)
> > + return irq_count;
> > +
> > + for (i = 0; i < irq_count; i++) {
> > + struct vgic_irq *irq = vgic_get_irq(kvm, NULL, intids[i]);
> > + if (!irq)
> > + continue;
> > + update_lpi_config(kvm, irq, vcpu, false);
> > + vgic_put_irq(kvm, irq);
> > + }
> > +
> > + kfree(intids);
> > +
> > + if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm)
> > + its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe);
> > +
> > + return 0;
> > }
>
> nit: the refactoring happening at the same time as the functional change
> is a bit distracting. Looks fine though.
Yeah, it didn't seem to warrant an extra patch, given that we're
really only moving things about.
>
> > /*
> > @@ -1305,32 +1344,13 @@ static int vgic_its_cmd_handle_invall(struct kvm *kvm, struct vgic_its *its,
> > u32 coll_id = its_cmd_get_collection(its_cmd);
> > struct its_collection *collection;
> > struct kvm_vcpu *vcpu;
> > - struct vgic_irq *irq;
> > - u32 *intids;
> > - int irq_count, i;
> >
> > collection = find_collection(its, coll_id);
> > if (!its_is_collection_mapped(collection))
> > return E_ITS_INVALL_UNMAPPED_COLLECTION;
> >
> > vcpu = kvm_get_vcpu(kvm, collection->target_addr);
> > -
> > - irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids);
> > - if (irq_count < 0)
> > - return irq_count;
> > -
> > - for (i = 0; i < irq_count; i++) {
> > - irq = vgic_get_irq(kvm, NULL, intids[i]);
> > - if (!irq)
> > - continue;
> > - update_lpi_config(kvm, irq, vcpu, false);
> > - vgic_put_irq(kvm, irq);
> > - }
> > -
> > - kfree(intids);
> > -
> > - if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm)
> > - its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe);
> > + vgic_its_invall(vcpu);
> >
> > return 0;
> > }
> > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > index 58e40b4874f8..186bf35078bf 100644
> > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > @@ -525,6 +525,59 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> > pendbaser) != old_pendbaser);
> > }
> >
> > +static unsigned long vgic_mmio_read_sync(struct kvm_vcpu *vcpu,
> > + gpa_t addr, unsigned int len)
> > +{
> > + return !!atomic_read(&vcpu->arch.vgic_cpu.syncr_busy);
> > +}
> > +
> > +static void vgic_make_rdist_busy(struct kvm_vcpu *vcpu, bool busy)
>
> nit: s/make/set, since you use this helper to decrement the counter too.
Sure, works for me.
> > +{
> > + if (busy) {
> > + atomic_inc(&vcpu->arch.vgic_cpu.syncr_busy);
> > + smp_mb__after_atomic();
> > + } else {
> > + smp_mb__before_atomic();
> > + atomic_dec(&vcpu->arch.vgic_cpu.syncr_busy);
> > + }
> > +}
> > +
> > +static void vgic_mmio_write_invlpi(struct kvm_vcpu *vcpu,
> > + gpa_t addr, unsigned int len,
> > + unsigned long val)
> > +{
> > + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> > + struct vgic_irq *irq;
> > +
> > + if (!vgic_cpu->lpis_enabled)
> > + return;
> > +
> > + vgic_make_rdist_busy(vcpu, true);
> > +
> > + irq = vgic_get_irq(vcpu->kvm, NULL, val);
> > + if (!irq)
> > + return;
>
> Isn't the busy counter unbalanced if you return early?
Huh, well caught. Fix incoming.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
kvmarm@lists.cs.columbia.edu, kernel-team@android.com,
Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH 2/4] KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation
Date: Wed, 16 Mar 2022 09:31:48 +0000 [thread overview]
Message-ID: <87bky6z1iz.wl-maz@kernel.org> (raw)
In-Reply-To: <YjF07lltAEn6X22V@google.com>
On Wed, 16 Mar 2022 05:26:06 +0000,
Oliver Upton <oupton@google.com> wrote:
>
> Hi Marc,
>
> On Mon, Mar 14, 2022 at 04:40:42PM +0000, Marc Zyngier wrote:
> > Since GICv4.1, it has become legal for an implementation to advertise
> > GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more
> > efficient invalidation scheme (no guest command queue contention when
> > multiple CPUs are generating invalidations).
> >
> > Provide the invalidation registers as a primitive to their ITS
> > counterpart. Note that we don't advertise them to the guest yet
> > (the architecture allows an implementation to do this).
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/vgic/vgic-its.c | 62 ++++++++++++++++++++----------
> > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 62 ++++++++++++++++++++++++++++++
> > arch/arm64/kvm/vgic/vgic.h | 4 ++
> > include/kvm/arm_vgic.h | 1 +
> > 4 files changed, 108 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
> > index 089fc2ffcb43..cc62d8a8180f 100644
> > --- a/arch/arm64/kvm/vgic/vgic-its.c
> > +++ b/arch/arm64/kvm/vgic/vgic-its.c
> > @@ -1272,6 +1272,11 @@ static int vgic_its_cmd_handle_clear(struct kvm *kvm, struct vgic_its *its,
> > return 0;
> > }
> >
> > +int vgic_its_inv_lpi(struct kvm *kvm, struct vgic_irq *irq)
> > +{
> > + return update_lpi_config(kvm, irq, NULL, true);
> > +}
> > +
> > /*
> > * The INV command syncs the configuration bits from the memory table.
> > * Must be called with the its_lock mutex held.
> > @@ -1288,7 +1293,41 @@ static int vgic_its_cmd_handle_inv(struct kvm *kvm, struct vgic_its *its,
> > if (!ite)
> > return E_ITS_INV_UNMAPPED_INTERRUPT;
> >
> > - return update_lpi_config(kvm, ite->irq, NULL, true);
> > + return vgic_its_inv_lpi(kvm, ite->irq);
> > +}
> > +
> > +/**
> > + * vgic_its_invall - invalidate all LPIs targetting a given vcpu
> > + * @vcpu: the vcpu for which the RD is targetted by an invalidation
> > + *
> > + * Contrary to the INVALL command, this targets a RD instead of a
> > + * collection, and we don't need to hold the its_lock, since no ITS is
> > + * involved here.
> > + */
> > +int vgic_its_invall(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm *kvm = vcpu->kvm;
> > + int irq_count, i = 0;
> > + u32 *intids;
> > +
> > + irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids);
> > + if (irq_count < 0)
> > + return irq_count;
> > +
> > + for (i = 0; i < irq_count; i++) {
> > + struct vgic_irq *irq = vgic_get_irq(kvm, NULL, intids[i]);
> > + if (!irq)
> > + continue;
> > + update_lpi_config(kvm, irq, vcpu, false);
> > + vgic_put_irq(kvm, irq);
> > + }
> > +
> > + kfree(intids);
> > +
> > + if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm)
> > + its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe);
> > +
> > + return 0;
> > }
>
> nit: the refactoring happening at the same time as the functional change
> is a bit distracting. Looks fine though.
Yeah, it didn't seem to warrant an extra patch, given that we're
really only moving things about.
>
> > /*
> > @@ -1305,32 +1344,13 @@ static int vgic_its_cmd_handle_invall(struct kvm *kvm, struct vgic_its *its,
> > u32 coll_id = its_cmd_get_collection(its_cmd);
> > struct its_collection *collection;
> > struct kvm_vcpu *vcpu;
> > - struct vgic_irq *irq;
> > - u32 *intids;
> > - int irq_count, i;
> >
> > collection = find_collection(its, coll_id);
> > if (!its_is_collection_mapped(collection))
> > return E_ITS_INVALL_UNMAPPED_COLLECTION;
> >
> > vcpu = kvm_get_vcpu(kvm, collection->target_addr);
> > -
> > - irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids);
> > - if (irq_count < 0)
> > - return irq_count;
> > -
> > - for (i = 0; i < irq_count; i++) {
> > - irq = vgic_get_irq(kvm, NULL, intids[i]);
> > - if (!irq)
> > - continue;
> > - update_lpi_config(kvm, irq, vcpu, false);
> > - vgic_put_irq(kvm, irq);
> > - }
> > -
> > - kfree(intids);
> > -
> > - if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm)
> > - its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe);
> > + vgic_its_invall(vcpu);
> >
> > return 0;
> > }
> > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > index 58e40b4874f8..186bf35078bf 100644
> > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> > @@ -525,6 +525,59 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> > pendbaser) != old_pendbaser);
> > }
> >
> > +static unsigned long vgic_mmio_read_sync(struct kvm_vcpu *vcpu,
> > + gpa_t addr, unsigned int len)
> > +{
> > + return !!atomic_read(&vcpu->arch.vgic_cpu.syncr_busy);
> > +}
> > +
> > +static void vgic_make_rdist_busy(struct kvm_vcpu *vcpu, bool busy)
>
> nit: s/make/set, since you use this helper to decrement the counter too.
Sure, works for me.
> > +{
> > + if (busy) {
> > + atomic_inc(&vcpu->arch.vgic_cpu.syncr_busy);
> > + smp_mb__after_atomic();
> > + } else {
> > + smp_mb__before_atomic();
> > + atomic_dec(&vcpu->arch.vgic_cpu.syncr_busy);
> > + }
> > +}
> > +
> > +static void vgic_mmio_write_invlpi(struct kvm_vcpu *vcpu,
> > + gpa_t addr, unsigned int len,
> > + unsigned long val)
> > +{
> > + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> > + struct vgic_irq *irq;
> > +
> > + if (!vgic_cpu->lpis_enabled)
> > + return;
> > +
> > + vgic_make_rdist_busy(vcpu, true);
> > +
> > + irq = vgic_get_irq(vcpu->kvm, NULL, val);
> > + if (!irq)
> > + return;
>
> Isn't the busy counter unbalanced if you return early?
Huh, well caught. Fix incoming.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-03-16 9:32 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 16:40 [PATCH 0/4] KVM: arm64: vgic-v3: MMIO-based LPI invalidation and co Marc Zyngier
2022-03-14 16:40 ` Marc Zyngier
2022-03-14 16:40 ` Marc Zyngier
2022-03-14 16:40 ` [PATCH 1/4] irqchip/gic-v3: Exposes bit values for GICR_CTLR.{IR, CES} Marc Zyngier
2022-03-14 16:40 ` [PATCH 1/4] irqchip/gic-v3: Exposes bit values for GICR_CTLR.{IR,CES} Marc Zyngier
2022-03-14 16:40 ` [PATCH 1/4] irqchip/gic-v3: Exposes bit values for GICR_CTLR.{IR, CES} Marc Zyngier
2022-03-15 23:16 ` Oliver Upton
2022-03-15 23:16 ` Oliver Upton
2022-03-15 23:16 ` Oliver Upton
2022-03-16 9:29 ` Marc Zyngier
2022-03-16 9:29 ` Marc Zyngier
2022-03-16 9:29 ` Marc Zyngier
2022-03-14 16:40 ` [PATCH 2/4] KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation Marc Zyngier
2022-03-14 16:40 ` Marc Zyngier
2022-03-14 16:40 ` Marc Zyngier
2022-03-16 5:26 ` Oliver Upton
2022-03-16 5:26 ` Oliver Upton
2022-03-16 5:26 ` Oliver Upton
2022-03-16 9:31 ` Marc Zyngier [this message]
2022-03-16 9:31 ` Marc Zyngier
2022-03-16 9:31 ` Marc Zyngier
2022-03-14 16:40 ` [PATCH 3/4] KVM: arm64: vgic-v3: Expose GICR_CTLR.RWP when disabling LPIs Marc Zyngier
2022-03-14 16:40 ` Marc Zyngier
2022-03-14 16:40 ` Marc Zyngier
2022-03-16 5:39 ` Oliver Upton
2022-03-16 5:39 ` Oliver Upton
2022-03-16 5:39 ` Oliver Upton
2022-03-14 16:40 ` [PATCH 4/4] KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision Marc Zyngier
2022-03-14 16:40 ` [PATCH 4/4] KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR,CES} " Marc Zyngier
2022-03-14 16:40 ` [PATCH 4/4] KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} " Marc Zyngier
2022-03-15 23:13 ` Oliver Upton
2022-03-15 23:13 ` Oliver Upton
2022-03-15 23:13 ` Oliver Upton
2022-03-16 9:27 ` Marc Zyngier
2022-03-16 9:27 ` Marc Zyngier
2022-03-16 9:27 ` Marc Zyngier
2022-03-16 15:01 ` Marc Zyngier
2022-03-16 15:01 ` Marc Zyngier
2022-03-16 15:01 ` 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=87bky6z1iz.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=andre.przywara@arm.com \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oupton@google.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.