public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Anton Romanov <romanton@google.com>
Cc: mtosatti@redhat.com, Anton Romanov <romanton@google.com>,
	kvm@vger.kernel.org, pbonzini@redhat.com
Subject: Re: [PATCH v2] kvm: x86: Disable KVM_HC_CLOCK_PAIRING if tsc is in always catchup mode
Date: Wed, 16 Feb 2022 15:14:22 +0100	[thread overview]
Message-ID: <87zgmqq4ox.fsf@redhat.com> (raw)
In-Reply-To: <20220215200116.4022789-1-romanton@google.com>

Anton Romanov <romanton@google.com> writes:

> If vcpu has tsc_always_catchup set each request updates pvclock data.
> KVM_HC_CLOCK_PAIRING consumers such as ptp_kvm_x86 rely on tsc read on
> host's side and do hypercall inside pvclock_read_retry loop leading to
> infinite loop in such situation.
>
> v2:
>     Added warn
>
> Signed-off-by: Anton Romanov <romanton@google.com>
> ---
>  arch/x86/kvm/x86.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 7131d735b1ef..aaafb46a6048 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8945,6 +8945,15 @@ static int kvm_pv_clock_pairing(struct kvm_vcpu *vcpu, gpa_t paddr,
>  	if (!kvm_get_walltime_and_clockread(&ts, &cycle))
>  		return -KVM_EOPNOTSUPP;
>  
> +	/*
> +	 * When tsc is in permanent catchup mode guests won't be able to use
> +	 * pvclock_read_retry loop to get consistent view of pvclock
> +	 */
> +	if (vcpu->arch.tsc_always_catchup) {
> +		pr_warn_ratelimited("KVM_HC_CLOCK_PAIRING not supported if vcpu is in tsc catchup mode\n");
> +		return -KVM_EOPNOTSUPP;

I'm not sure this warn is a good idea. It is guest triggerable and
'tsc_always_catchup' is not a bug, it is a perfectly valid situation in
the configuration when TSC scaling is unavailable. Even ratelimited,
it's not nice when guests can pollute host's logs.

Also, EOPNOTSUPP makes it sound like the hypercall is unsupported, I'd
suggest changing this to KVM_EFAULT.

> +	}
> +
>  	clock_pairing.sec = ts.tv_sec;
>  	clock_pairing.nsec = ts.tv_nsec;
>  	clock_pairing.tsc = kvm_read_l1_tsc(vcpu, cycle);

-- 
Vitaly


  reply	other threads:[~2022-02-16 14:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 20:01 [PATCH v2] kvm: x86: Disable KVM_HC_CLOCK_PAIRING if tsc is in always catchup mode Anton Romanov
2022-02-16 14:14 ` Vitaly Kuznetsov [this message]
2022-02-17 15:41   ` Sean Christopherson
2022-02-17 16:09     ` Vitaly Kuznetsov
2022-02-17 17:14       ` Paolo Bonzini
2022-02-17 17:16         ` Vitaly Kuznetsov
2022-02-17 17:39           ` Paolo Bonzini

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=87zgmqq4ox.fsf@redhat.com \
    --to=vkuznets@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=romanton@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox