linux-kernel - Re: [patch V2 17/17] x86/kvm: Use generic exit to guest work function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191023144848.GH329@linux.intel.com>
Date:   Wed, 23 Oct 2019 07:48:48 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Will Deacon <will@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-arch@...r.kernel.org, Mike Rapoport <rppt@...ux.ibm.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Miroslav Benes <mbenes@...e.cz>
Subject: Re: [patch V2 17/17] x86/kvm: Use generic exit to guest work function

On Wed, Oct 23, 2019 at 02:27:22PM +0200, Thomas Gleixner wrote:
> Use the generic infrastructure to check for and handle pending work before
> entering into guest mode.
> 
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---
>  arch/x86/kvm/Kconfig |    1 +
>  arch/x86/kvm/x86.c   |   17 +++++------------
>  2 files changed, 6 insertions(+), 12 deletions(-)
> 
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -42,6 +42,7 @@ config KVM
>  	select HAVE_KVM_MSI
>  	select HAVE_KVM_CPU_RELAX_INTERCEPT
>  	select HAVE_KVM_NO_POLL
> +	select KVM_EXIT_TO_GUEST_WORK
>  	select KVM_GENERIC_DIRTYLOG_READ_PROTECT
>  	select KVM_VFIO
>  	select SRCU
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -52,6 +52,7 @@
>  #include <linux/irqbypass.h>
>  #include <linux/sched/stat.h>
>  #include <linux/sched/isolation.h>
> +#include <linux/entry-common.h>
>  #include <linux/mem_encrypt.h>
>  
>  #include <trace/events/kvm.h>
> @@ -8115,8 +8116,8 @@ static int vcpu_enter_guest(struct kvm_v
>  	if (kvm_lapic_enabled(vcpu) && vcpu->arch.apicv_active)
>  		kvm_x86_ops->sync_pir_to_irr(vcpu);
>  
> -	if (vcpu->mode == EXITING_GUEST_MODE || kvm_request_pending(vcpu)
> -	    || need_resched() || signal_pending(current)) {
> +	if (vcpu->mode == EXITING_GUEST_MODE || kvm_request_pending(vcpu) ||
> +	    exit_to_guestmode_work_pending()) {

The terms EXIT_TO_GUEST and exit_to_guestmode are very confusing, as
they're inverted from the usual virt terminology of VM-Enter (enter guest)
and VM-Exit (exit guest).  The conflict is most obvious here, with the
above "vcpu->mode == EXITING_GUEST_MODE", which is checking to see if the
vCPU is being forced to exit *from* guest mode because was kicked by some
other part of KVM.

Maybe XFER_TO_GUEST?  I.e. avoid entry/exit entirely, so that neither the
entry code or KVM ends up with a confusing name.

>  		vcpu->mode = OUTSIDE_GUEST_MODE;
>  		smp_wmb();
>  		local_irq_enable();
> @@ -8309,17 +8310,9 @@ static int vcpu_run(struct kvm_vcpu *vcp
>  
>  		kvm_check_async_pf_completion(vcpu);
>  
> -		if (signal_pending(current)) {
> -			r = -EINTR;
> -			vcpu->run->exit_reason = KVM_EXIT_INTR;
> -			++vcpu->stat.signal_exits;
> +		r = exit_to_guestmode(kvm, vcpu);

Ditto here.  If the run loop is stripped down to the core functionality,
it effectively looks like:

	for (;;) {
		r = vcpu_enter_guest(vcpu);
		if (r <= 0)
			break;

		...

		r = exit_to_guestmode(kvm, vcpu);
		if (r)
			break;
	}

Appending _handle_work to the function would also be helpful so that it's
somewhat clear the function isn't related to the core vcpu_enter_guest()
functionality, e.g.:

	for (;;) {
		r = vcpu_enter_guest(vcpu);
		if (r <= 0)
			break;

		...

		r = xfer_to_guestmode_handle_work(kvm, vcpu);
		if (r)
			break;
	}


> +		if (r)
>  			break;
> -		}
> -		if (need_resched()) {
> -			srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
> -			cond_resched();
> -			vcpu->srcu_idx = srcu_read_lock(&kvm->srcu);
> -		}
>  	}
>  
>  	srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
> 
>