All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
@ 2020-01-19 13:30 ` Zenghui Yu
  0 siblings, 0 replies; 4+ messages in thread
From: Zenghui Yu @ 2020-01-19 13:30 UTC (permalink / raw)
  To: peter.maydell, qemu-arm, qemu-devel
  Cc: Zenghui Yu, maz, kvmarm, wanghaibin.wang, eric.auger

If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when
restoring GICR_CTLR.  Setting PTZ here makes littlt sense in "reduce GIC
initialization time".

And what's worse, PTZ is generally programmed by guest to indicate to the
Redistributor whether the LPI Pending table is zero when enabling LPIs.
If migration is triggered when the PTZ has just been cleared by guest (and
before enabling LPIs), we will see PTZ==1 on the destination side, which
is not as expected.  Let's just drop this hackish userspace behavior.

Also take this chance to refine the comment a bit.

Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
 hw/intc/arm_gicv3_kvm.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index 9c7f4ab871..49304ca589 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -336,7 +336,10 @@ static void kvm_arm_gicv3_put(GICv3State *s)
     kvm_gicd_access(s, GICD_CTLR, &reg, true);
 
     if (redist_typer & GICR_TYPER_PLPIS) {
-        /* Set base addresses before LPIs are enabled by GICR_CTLR write */
+        /*
+         * Restore base addresses before LPIs are potentially enabled by
+         * GICR_CTLR write
+         */
         for (ncpu = 0; ncpu < s->num_cpu; ncpu++) {
             GICv3CPUState *c = &s->cpu[ncpu];
 
@@ -347,12 +350,6 @@ static void kvm_arm_gicv3_put(GICv3State *s)
             kvm_gicr_access(s, GICR_PROPBASER + 4, ncpu, &regh, true);
 
             reg64 = c->gicr_pendbaser;
-            if (!(c->gicr_ctlr & GICR_CTLR_ENABLE_LPIS)) {
-                /* Setting PTZ is advised if LPIs are disabled, to reduce
-                 * GIC initialization time.
-                 */
-                reg64 |= GICR_PENDBASER_PTZ;
-            }
             regl = (uint32_t)reg64;
             kvm_gicr_access(s, GICR_PENDBASER, ncpu, &regl, true);
             regh = (uint32_t)(reg64 >> 32);
-- 
2.19.1




^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [PATCH] hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
@ 2020-01-19 13:30 ` Zenghui Yu
  0 siblings, 0 replies; 4+ messages in thread
From: Zenghui Yu @ 2020-01-19 13:30 UTC (permalink / raw)
  To: peter.maydell, qemu-arm, qemu-devel; +Cc: maz, kvmarm

If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when
restoring GICR_CTLR.  Setting PTZ here makes littlt sense in "reduce GIC
initialization time".

And what's worse, PTZ is generally programmed by guest to indicate to the
Redistributor whether the LPI Pending table is zero when enabling LPIs.
If migration is triggered when the PTZ has just been cleared by guest (and
before enabling LPIs), we will see PTZ==1 on the destination side, which
is not as expected.  Let's just drop this hackish userspace behavior.

Also take this chance to refine the comment a bit.

Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
 hw/intc/arm_gicv3_kvm.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index 9c7f4ab871..49304ca589 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -336,7 +336,10 @@ static void kvm_arm_gicv3_put(GICv3State *s)
     kvm_gicd_access(s, GICD_CTLR, &reg, true);
 
     if (redist_typer & GICR_TYPER_PLPIS) {
-        /* Set base addresses before LPIs are enabled by GICR_CTLR write */
+        /*
+         * Restore base addresses before LPIs are potentially enabled by
+         * GICR_CTLR write
+         */
         for (ncpu = 0; ncpu < s->num_cpu; ncpu++) {
             GICv3CPUState *c = &s->cpu[ncpu];
 
@@ -347,12 +350,6 @@ static void kvm_arm_gicv3_put(GICv3State *s)
             kvm_gicr_access(s, GICR_PROPBASER + 4, ncpu, &regh, true);
 
             reg64 = c->gicr_pendbaser;
-            if (!(c->gicr_ctlr & GICR_CTLR_ENABLE_LPIS)) {
-                /* Setting PTZ is advised if LPIs are disabled, to reduce
-                 * GIC initialization time.
-                 */
-                reg64 |= GICR_PENDBASER_PTZ;
-            }
             regl = (uint32_t)reg64;
             kvm_gicr_access(s, GICR_PENDBASER, ncpu, &regl, true);
             regh = (uint32_t)(reg64 >> 32);
-- 
2.19.1


_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
  2020-01-19 13:30 ` Zenghui Yu
@ 2020-01-30 14:03   ` Peter Maydell
  -1 siblings, 0 replies; 4+ messages in thread
From: Peter Maydell @ 2020-01-30 14:03 UTC (permalink / raw)
  To: Zenghui Yu
  Cc: Marc Zyngier, QEMU Developers, Eric Auger, qemu-arm,
	wanghaibin.wang, kvmarm

On Sun, 19 Jan 2020 at 13:32, Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when
> restoring GICR_CTLR.  Setting PTZ here makes littlt sense in "reduce GIC
> initialization time".
>
> And what's worse, PTZ is generally programmed by guest to indicate to the
> Redistributor whether the LPI Pending table is zero when enabling LPIs.
> If migration is triggered when the PTZ has just been cleared by guest (and
> before enabling LPIs), we will see PTZ==1 on the destination side, which
> is not as expected.  Let's just drop this hackish userspace behavior.
>
> Also take this chance to refine the comment a bit.

I pulled up the original code-review discussion where this code
was added:
https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg05889.html

It looks like the original reason for adding it was that the
GICR_PENDBASER.PTZ bit is write-only, and so there's no way for
the migration code in QEMU to accurately restore it on the
destination end of a migration. So Pavel picked a heuristic
for guessing what the right value of the PTZ bit was.

It sounds like the penalty if userspace sets the bit to 0
always on a migration is not significant, so I guess that
just setting this bit to 0 always is an OK thing to do (as you
say, there's a window in the existing implementation where
we do the wrong thing sometimes if migration happens at the
wrong time, because the current code's heuristic can
sometimes fail in the wrong direction).

Applied to target-arm.next.

thanks
-- PMM


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
@ 2020-01-30 14:03   ` Peter Maydell
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Maydell @ 2020-01-30 14:03 UTC (permalink / raw)
  To: Zenghui Yu; +Cc: Marc Zyngier, QEMU Developers, qemu-arm, kvmarm

On Sun, 19 Jan 2020 at 13:32, Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when
> restoring GICR_CTLR.  Setting PTZ here makes littlt sense in "reduce GIC
> initialization time".
>
> And what's worse, PTZ is generally programmed by guest to indicate to the
> Redistributor whether the LPI Pending table is zero when enabling LPIs.
> If migration is triggered when the PTZ has just been cleared by guest (and
> before enabling LPIs), we will see PTZ==1 on the destination side, which
> is not as expected.  Let's just drop this hackish userspace behavior.
>
> Also take this chance to refine the comment a bit.

I pulled up the original code-review discussion where this code
was added:
https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg05889.html

It looks like the original reason for adding it was that the
GICR_PENDBASER.PTZ bit is write-only, and so there's no way for
the migration code in QEMU to accurately restore it on the
destination end of a migration. So Pavel picked a heuristic
for guessing what the right value of the PTZ bit was.

It sounds like the penalty if userspace sets the bit to 0
always on a migration is not significant, so I guess that
just setting this bit to 0 always is an OK thing to do (as you
say, there's a window in the existing implementation where
we do the wrong thing sometimes if migration happens at the
wrong time, because the current code's heuristic can
sometimes fail in the wrong direction).

Applied to target-arm.next.

thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-01-30 14:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-19 13:30 [PATCH] hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit Zenghui Yu
2020-01-19 13:30 ` Zenghui Yu
2020-01-30 14:03 ` Peter Maydell
2020-01-30 14:03   ` Peter Maydell

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.