Re: [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 23 Sep 2021 20:16:04 +0100,
Oliver Upton <oupton@xxxxxxxxxx> wrote:
> 
> The emulation of WFI-like instructions (WFI, PSCI CPU_SUSPEND) is done
> by calling kvm_vcpu_block() directly from the respective exit handlers.
> A subsequent change to KVM will allow userspace to request a vCPU be
> suspended on the next KVM_RUN, necessitating a deferral mechanism for
> WFI emulation.
> 
> Refactor such that there is a single WFI implementation which may be
> requested with KVM_REQ_SUSPEND. Request WFI emulation from the
> aforementioned handlers by making this request.
> 
> Signed-off-by: Oliver Upton <oupton@xxxxxxxxxx>
> ---
>  arch/arm64/include/asm/kvm_host.h | 1 +
>  arch/arm64/kvm/arm.c              | 9 +++++++++
>  arch/arm64/kvm/handle_exit.c      | 3 +--
>  arch/arm64/kvm/psci.c             | 4 +---
>  4 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index f8be56d5342b..1beda1189a15 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -47,6 +47,7 @@
>  #define KVM_REQ_RECORD_STEAL	KVM_ARCH_REQ(3)
>  #define KVM_REQ_RELOAD_GICv4	KVM_ARCH_REQ(4)
>  #define KVM_REQ_RELOAD_PMU	KVM_ARCH_REQ(5)
> +#define KVM_REQ_SUSPEND		KVM_ARCH_REQ(6)
>  
>  #define KVM_DIRTY_LOG_MANUAL_CAPS   (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
>  				     KVM_DIRTY_LOG_INITIALLY_SET)
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 3d4acd354f94..f1a375648e25 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -670,6 +670,12 @@ static void kvm_vcpu_sleep(struct kvm_vcpu *vcpu)
>  	smp_rmb();
>  }
>  
> +static void kvm_vcpu_suspend(struct kvm_vcpu *vcpu)

Bike-shed alert: I would really prefer this to have 'wfi' in the
function name, because we implement suspend in terms of WFI rather
than the other way around.

> +{
> +	kvm_vcpu_block(vcpu);
> +	kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> +}
> +
>  static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
>  {
>  	return vcpu->arch.target >= 0;
> @@ -681,6 +687,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
>  		if (kvm_check_request(KVM_REQ_SLEEP, vcpu))
>  			kvm_vcpu_sleep(vcpu);
>  
> +		if (kvm_check_request(KVM_REQ_SUSPEND, vcpu))
> +			kvm_vcpu_suspend(vcpu);
> +
>  		if (kvm_check_request(KVM_REQ_VCPU_RESET, vcpu))
>  			kvm_reset_vcpu(vcpu);
>  
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 275a27368a04..5e5ef9ff4fba 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -95,8 +95,7 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
>  	} else {
>  		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false);
>  		vcpu->stat.wfi_exit_stat++;
> -		kvm_vcpu_block(vcpu);
> -		kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> +		kvm_make_request(KVM_REQ_SUSPEND, vcpu);
>  	}
>  
>  	kvm_incr_pc(vcpu);

This is a change in behaviour. At the point where the blocking
happens, PC will have already been incremented. I'd rather you don't
do that. Instead, make the helper available and call into it directly,
preserving the current semantics.

It is also likely to clash with Sean's kvm_vcpu_block() rework, but we
can work around that.

> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
> index bb59b692998b..d453666ddb83 100644
> --- a/arch/arm64/kvm/psci.c
> +++ b/arch/arm64/kvm/psci.c
> @@ -46,9 +46,7 @@ static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu)
>  	 * specification (ARM DEN 0022A). This means all suspend states
>  	 * for KVM will preserve the register state.
>  	 */
> -	kvm_vcpu_block(vcpu);
> -	kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> -
> +	kvm_make_request(KVM_REQ_SUSPEND, vcpu);
>  	return PSCI_RET_SUCCESS;
>  }

I have similar feelings about this one, although things only breaks
once you enable NV (SMC is trapped and subject to PC adjustments).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux