All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Oliver Upton <oupton@google.com>, Peter Shier <pshier@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] KVM: x86: Don't attempt to load PDPTRs when 64-bit mode is enabled
Date: Tue, 14 Jul 2020 14:00:04 +0200	[thread overview]
Message-ID: <87wo36s3wb.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200714015732.32426-1-sean.j.christopherson@intel.com>

Sean Christopherson <sean.j.christopherson@intel.com> writes:

> Don't attempt to load PDPTRs if EFER.LME=1, i.e. if 64-bit mode is
> enabled.  A recent change to reload the PDTPRs when CR0.CD or CR0.NW is
> toggled botched the EFER.LME handling and sends KVM down the PDTPR path
> when is_paging() is true, i.e. when the guest toggles CD/NW in 64-bit
> mode.
>
> Split the CR0 checks for 64-bit vs. 32-bit PAE into separate paths.  The
> 64-bit path is specifically checking state when paging is toggled on,
> i.e. CR0.PG transititions from 0->1.  The PDPTR path now needs to run if
> the new CR0 state has paging enabled, irrespective of whether paging was
> already enabled.  Trying to shave a few cycles to make the PDPTR path an
> "else if" case is a mess.
>
> Fixes: d42e3fae6faed ("kvm: x86: Read PDPTEs on CR0.CD and CR0.NW changes")
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Oliver Upton <oupton@google.com>
> Cc: Peter Shier <pshier@google.com>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> ---
>
> The other way to fix this, with a much smaller diff stat, is to simply
> move the !is_page(vcpu) check inside (vcpu->arch.efer & EFER_LME).  But
> that results in a ridiculous amount of nested conditionals for what is a
> very straightforward check e.g.
>
> 	if (cr0 & X86_CR0_PG) {
> 		if (vcpu->arch.efer & EFER_LME) }
> 			if (!is_paging(vcpu)) {
> 				...
> 			}
> 		}
> 	}
>
> Since this doesn't need to be backported anywhere, I didn't see any value
> in having an intermediate step.
>
>  arch/x86/kvm/x86.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 95ef629228691..5f526d94c33f3 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -819,22 +819,22 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
>  	if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE))
>  		return 1;
>  
> -	if (cr0 & X86_CR0_PG) {
>  #ifdef CONFIG_X86_64
> -		if (!is_paging(vcpu) && (vcpu->arch.efer & EFER_LME)) {
> -			int cs_db, cs_l;
> +	if ((vcpu->arch.efer & EFER_LME) && !is_paging(vcpu) &&
> +	    (cr0 & X86_CR0_PG)) {

it seems we have more than one occurance of "if (vcpu->arch.efer &
EFER_LME)" under "#ifdef CONFIG_X86_64" and we alredy have 

static inline int is_long_mode(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_X86_64
     return vcpu->arch.efer & EFER_LMA;
#else
     return 0;
#endif
}

so if we use this instead, the compilers will just throw away the
non-reachable blocks when !(#ifdef CONFIG_X86_64), right?

> +		int cs_db, cs_l;
>  
> -			if (!is_pae(vcpu))
> -				return 1;
> -			kvm_x86_ops.get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
> -			if (cs_l)
> -				return 1;
> -		} else
> -#endif
> -		if (is_pae(vcpu) && ((cr0 ^ old_cr0) & pdptr_bits) &&
> -		    !load_pdptrs(vcpu, vcpu->arch.walk_mmu, kvm_read_cr3(vcpu)))
> +		if (!is_pae(vcpu))
> +			return 1;
> +		kvm_x86_ops.get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
> +		if (cs_l)
>  			return 1;
>  	}
> +#endif
> +	if (!(vcpu->arch.efer & EFER_LME) && (cr0 & X86_CR0_PG) &&
> +	    is_pae(vcpu) && ((cr0 ^ old_cr0) & pdptr_bits) &&
> +	    !load_pdptrs(vcpu, vcpu->arch.walk_mmu, kvm_read_cr3(vcpu)))
> +		return 1;
>  
>  	if (!(cr0 & X86_CR0_PG) && kvm_read_cr4_bits(vcpu, X86_CR4_PCIDE))
>  		return 1;

-- 
Vitaly


  reply	other threads:[~2020-07-14 12:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  1:57 [PATCH] KVM: x86: Don't attempt to load PDPTRs when 64-bit mode is enabled Sean Christopherson
2020-07-14 12:00 ` Vitaly Kuznetsov [this message]
2020-07-14 13:21   ` Sean Christopherson
2020-07-14 14:11     ` Vitaly Kuznetsov
2020-07-14 18:55 ` Jim Mattson
2020-07-14 18:58   ` Sean Christopherson
2020-07-14 19:02     ` Jim Mattson
2020-08-04 18:41 ` Sean Christopherson
2020-08-04 18:46   ` Jim Mattson
2020-08-04 19:09     ` Sean Christopherson
2020-08-05  7:04 ` Maxim Levitsky
2020-08-06 21:32   ` Jim Mattson

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=87wo36s3wb.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=wanpengli@tencent.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.