All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>, kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Jim Mattson <jmattson@google.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Ingo Molnar <mingo@redhat.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Joerg Roedel <joro@8bytes.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v2 1/1] KVM: x86: fix MSR_IA32_TSC read for nested migration
Date: Thu, 24 Sep 2020 19:33:09 +0200	[thread overview]
Message-ID: <a35f7d67-d01b-0b2a-2993-7d6e0ba4add6@redhat.com> (raw)
In-Reply-To: <20200921103805.9102-2-mlevitsk@redhat.com>

On 21/09/20 12:38, Maxim Levitsky wrote:
> MSR reads/writes should always access the L1 state, since the (nested)
> hypervisor should intercept all the msrs it wants to adjust, and these
> that it doesn't should be read by the guest as if the host had read it.
> 
> However IA32_TSC is an exception. Even when not intercepted, guest still
> reads the value + TSC offset.
> The write however does not take any TSC offset into account.
> 
> This is documented in Intel's SDM and seems also to happen on AMD as well.
> 
> This creates a problem when userspace wants to read the IA32_TSC value and then
> write it. (e.g for migration)
> 
> In this case it reads L2 value but write is interpreted as an L1 value.
> To fix this make the userspace initiated reads of IA32_TSC return L1 value
> as well.
> 
> Huge thanks to Dave Gilbert for helping me understand this very confusing
> semantic of MSR writes.
> 
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> ---
>  arch/x86/kvm/x86.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 17f4995e80a7e..ed4314641360e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3219,9 +3219,21 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  	case MSR_IA32_POWER_CTL:
>  		msr_info->data = vcpu->arch.msr_ia32_power_ctl;
>  		break;
> -	case MSR_IA32_TSC:
> -		msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + vcpu->arch.tsc_offset;
> +	case MSR_IA32_TSC: {
> +		/*
> +		 * Intel SDM states that MSR_IA32_TSC read adds the TSC offset
> +		 * even when not intercepted. AMD manual doesn't explicitly
> +		 * state this but appears to behave the same.
> +		 *
> +		 * However when userspace wants to read this MSR, we should
> +		 * return it's real L1 value so that its restore will be correct.
> +		 */
> +		u64 tsc_offset = msr_info->host_initiated ? vcpu->arch.l1_tsc_offset :
> +							    vcpu->arch.tsc_offset;
> +
> +		msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + tsc_offset;
>  		break;
> +	}
>  	case MSR_MTRRcap:
>  	case 0x200 ... 0x2ff:
>  		return kvm_mtrr_get_msr(vcpu, msr_info->index, &msr_info->data);
> 

Applied the patch as it is doing the sanest possible thing for the
current semantics of host-initiated accesses.

Paolo


  parent reply	other threads:[~2020-09-24 17:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21 10:38 [PATCH v2 0/1] KVM: correctly restore the TSC value on nested migration Maxim Levitsky
2020-09-21 10:38 ` [PATCH v2 1/1] KVM: x86: fix MSR_IA32_TSC read for " Maxim Levitsky
     [not found]   ` <20200921162326.GB23989@linux.intel.com>
2020-09-22 12:50     ` Paolo Bonzini
2020-09-22 14:50       ` Maxim Levitsky
2020-09-22 15:39         ` Maxim Levitsky
2020-09-22 16:39           ` Paolo Bonzini
2020-09-24 17:33   ` Paolo Bonzini [this message]
2020-09-30 14:37     ` Maxim Levitsky

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=a35f7d67-d01b-0b2a-2993-7d6e0ba4add6@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mlevitsk@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /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.