All of lore.kernel.org
 help / color / mirror / Atom feed
* [v1] KVM: s390: pv: fix external interruption loop not always detected
@ 2022-08-24 12:58 Nico Boehr
  2022-09-19  9:37 ` Christian Borntraeger
  0 siblings, 1 reply; 2+ messages in thread
From: Nico Boehr @ 2022-08-24 12:58 UTC (permalink / raw)
  To: borntraeger, frankja, imbrenda; +Cc: kvm, linux-s390

To determine whether the guest has caused an external interruption loop
upon code 20 (external interrupt) intercepts, the ext_new_psw needs to
be inspected to see whether external interrupts are enabled.

Under non-PV, ext_new_psw can simply be taken from guest lowcore. Under
PV, KVM can only access the encrypted guest lowcore and hence the
ext_new_psw must not be taken from guest lowcore.

handle_external_interrupt() incorrectly did that and hence was not able
to reliably tell whether an external interruption loop is happening or
not. False negatives cause spurious failures of my kvm-unit-test
for extint loops[1] under PV.

Since code 20 is only caused under PV if and only if the guest's
ext_new_psw is enabled for external interrupts, false positive detection
of a external interruption loop can not happen.

Fix this issue by instead looking at the guest PSW in the state
description. Since the PSW swap for external interrupt is done by the
ultravisor before the intercept is caused, this reliably tells whether
the guest is enabled for external interrupts in the ext_new_psw.

[1] https://lore.kernel.org/kvm/20220812062151.1980937-4-nrb@linux.ibm.com/

Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
---
 arch/s390/kvm/intercept.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
index 88112065d941..bf875da86289 100644
--- a/arch/s390/kvm/intercept.c
+++ b/arch/s390/kvm/intercept.c
@@ -285,9 +285,14 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu)
 
 	vcpu->stat.exit_external_interrupt++;
 
-	rc = read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &newpsw, sizeof(psw_t));
-	if (rc)
-		return rc;
+	if (kvm_s390_pv_cpu_is_protected(vcpu))
+		newpsw = vcpu->arch.sie_block->gpsw;
+	else {
+		rc = read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &newpsw, sizeof(psw_t));
+		if (rc)
+			return rc;
+	}
+
 	/* We can not handle clock comparator or timer interrupt with bad PSW */
 	if ((eic == EXT_IRQ_CLK_COMP || eic == EXT_IRQ_CPU_TIMER) &&
 	    (newpsw.mask & PSW_MASK_EXT))
-- 
2.35.3


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

* Re: [v1] KVM: s390: pv: fix external interruption loop not always detected
  2022-08-24 12:58 [v1] KVM: s390: pv: fix external interruption loop not always detected Nico Boehr
@ 2022-09-19  9:37 ` Christian Borntraeger
  0 siblings, 0 replies; 2+ messages in thread
From: Christian Borntraeger @ 2022-09-19  9:37 UTC (permalink / raw)
  To: Nico Boehr, frankja, imbrenda; +Cc: kvm, linux-s390



Am 24.08.22 um 14:58 schrieb Nico Boehr:
> To determine whether the guest has caused an external interruption loop
> upon code 20 (external interrupt) intercepts, the ext_new_psw needs to
> be inspected to see whether external interrupts are enabled.
> 
> Under non-PV, ext_new_psw can simply be taken from guest lowcore. Under
> PV, KVM can only access the encrypted guest lowcore and hence the
> ext_new_psw must not be taken from guest lowcore.
> 
> handle_external_interrupt() incorrectly did that and hence was not able
> to reliably tell whether an external interruption loop is happening or
> not. False negatives cause spurious failures of my kvm-unit-test
> for extint loops[1] under PV.
> 
> Since code 20 is only caused under PV if and only if the guest's
> ext_new_psw is enabled for external interrupts, false positive detection
> of a external interruption loop can not happen.
> 
> Fix this issue by instead looking at the guest PSW in the state
> description. Since the PSW swap for external interrupt is done by the
> ultravisor before the intercept is caused, this reliably tells whether
> the guest is enabled for external interrupts in the ext_new_psw.
> 
> [1] https://lore.kernel.org/kvm/20220812062151.1980937-4-nrb@linux.ibm.com/
> 
> Signed-off-by: Nico Boehr <nrb@linux.ibm.com>

Makes sense. Can you try to rephrase the comment of handle_external_interrupt
to explain a bit better what is going on. Right now this is

/**
  * handle_external_interrupt - used for external interruption interceptions
  * @vcpu: virtual cpu
  *
  * This interception only occurs if the CPUSTAT_EXT_INT bit was set, or if
  * the new PSW does not have external interrupts disabled. In the first case,
  * we've got to deliver the interrupt manually, and in the second case, we
  * drop to userspace to handle the situation there.
  */

And maybe we want to say something about the fact that this is for loop
detection.

Otherwise looks good.

> ---
>   arch/s390/kvm/intercept.c | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
> index 88112065d941..bf875da86289 100644
> --- a/arch/s390/kvm/intercept.c
> +++ b/arch/s390/kvm/intercept.c
> @@ -285,9 +285,14 @@ static int handle_external_interrupt(struct kvm_vcpu *vcpu)
>   
>   	vcpu->stat.exit_external_interrupt++;
>   
> -	rc = read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &newpsw, sizeof(psw_t));
> -	if (rc)
> -		return rc;
> +	if (kvm_s390_pv_cpu_is_protected(vcpu))
> +		newpsw = vcpu->arch.sie_block->gpsw;
> +	else {
> +		rc = read_guest_lc(vcpu, __LC_EXT_NEW_PSW, &newpsw, sizeof(psw_t));
> +		if (rc)
> +			return rc;
> +	}
> +
>   	/* We can not handle clock comparator or timer interrupt with bad PSW */
>   	if ((eic == EXT_IRQ_CLK_COMP || eic == EXT_IRQ_CPU_TIMER) &&
>   	    (newpsw.mask & PSW_MASK_EXT))

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

end of thread, other threads:[~2022-09-19  9:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-24 12:58 [v1] KVM: s390: pv: fix external interruption loop not always detected Nico Boehr
2022-09-19  9:37 ` Christian Borntraeger

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.