public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Takahiro Itazuri <itazur@amazon.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	 Vitaly Kuznetsov <vkuznets@redhat.com>,
	Fuad Tabba <tabba@google.com>,
	 Brendan Jackman <jackmanb@google.com>,
	David Hildenbrand <david@kernel.org>,
	 David Woodhouse <dwmw2@infradead.org>,
	Paul Durrant <pdurrant@amazon.com>,
	 Nikita Kalyazin <kalyazin@amazon.com>,
	Patrick Roy <patrick.roy@campus.lmu.de>,
	 Takahiro Itazuri <zulinx86@gmail.com>
Subject: Re: [RFC PATCH v2 1/7] KVM: x86: Avoid silent kvm-clock activation failures
Date: Thu, 5 Mar 2026 09:50:30 -0800	[thread overview]
Message-ID: <aanCZqjXd0YiSmjR@google.com> (raw)
In-Reply-To: <20260226135309.29493-2-itazur@amazon.com>

On Thu, Feb 26, 2026, Takahiro Itazuri wrote:
> kvm_write_system_time() previously ignored the return value of
> kvm_gpc_activate().  As a result, kvm-clock activation could fail
> silently, making debugging harder.
> 
> Propagate the return value so that the MSR write fail properly instead
> of continuing silently.

Hrm.  For better or worse, KVM's ABI when it comes to PV stuff is to silently
ignore failures.  I 100% agree it makes debugging painful, but it's unfortunately
also "safer" in many cases, e.g. often results in degraded behavior versus flat
out crashing the guest.

The other wrinkle is that success isn't actually guaranteed, because the actual
writes don't happen until KVM_RUN via kvm_guest_time_update(), i.e. only failing
in _some_ cases creates a weird ABI.

And most importantly, this would be a breaking change in guest- and user-visible
behavior.  So while I agree silently failing is ugly, all things considered I
think it's the least awful choice here :-/

> Signed-off-by: Takahiro Itazuri <itazur@amazon.com>
> ---
>  arch/x86/kvm/x86.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a447663d5eff..a729b8419b61 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2438,7 +2438,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock, int sec_hi_o
>  	kvm_write_guest(kvm, wall_clock, &version, sizeof(version));
>  }
>  
> -static void kvm_write_system_time(struct kvm_vcpu *vcpu, gpa_t system_time,
> +static int kvm_write_system_time(struct kvm_vcpu *vcpu, gpa_t system_time,
>  				  bool old_msr, bool host_initiated)
>  {
>  	struct kvm_arch *ka = &vcpu->kvm->arch;
> @@ -2455,12 +2455,12 @@ static void kvm_write_system_time(struct kvm_vcpu *vcpu, gpa_t system_time,
>  
>  	/* we verify if the enable bit is set... */
>  	if (system_time & 1)
> -		kvm_gpc_activate(&vcpu->arch.pv_time, system_time & ~1ULL,
> -				 sizeof(struct pvclock_vcpu_time_info));
> -	else
> -		kvm_gpc_deactivate(&vcpu->arch.pv_time);
> +		return kvm_gpc_activate(&vcpu->arch.pv_time,
> +					system_time & ~1ULL,
> +					sizeof(struct pvclock_vcpu_time_info));
>  
> -	return;
> +	kvm_gpc_deactivate(&vcpu->arch.pv_time);
> +	return 0;
>  }
>  
>  static uint32_t div_frac(uint32_t dividend, uint32_t divisor)
> @@ -4156,13 +4156,15 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  		if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE2))
>  			return 1;
>  
> -		kvm_write_system_time(vcpu, data, false, msr_info->host_initiated);
> +		if (kvm_write_system_time(vcpu, data, false, msr_info->host_initiated))
> +			return 1;
>  		break;
>  	case MSR_KVM_SYSTEM_TIME:
>  		if (!guest_pv_has(vcpu, KVM_FEATURE_CLOCKSOURCE))
>  			return 1;
>  
> -		kvm_write_system_time(vcpu, data, true,  msr_info->host_initiated);
> +		if (kvm_write_system_time(vcpu, data, true,  msr_info->host_initiated))
> +			return 1;
>  		break;
>  	case MSR_KVM_ASYNC_PF_EN:
>  		if (!guest_pv_has(vcpu, KVM_FEATURE_ASYNC_PF))
> -- 
> 2.50.1
> 

  reply	other threads:[~2026-03-05 17:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26 13:53 [RFC PATCH v2 0/7] KVM: pfncache: Add guest_memfd support to pfncache Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 1/7] KVM: x86: Avoid silent kvm-clock activation failures Takahiro Itazuri
2026-03-05 17:50   ` Sean Christopherson [this message]
2026-03-10  5:58     ` Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 2/7] KVM: pfncache: Resolve PFNs via kvm_gmem_get_pfn() for gmem-backed GPAs Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 3/7] KVM: pfncache: Obtain KHVA via vmap() for gmem with NO_DIRECT_MAP Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 4/7] KVM: Rename invalidate_begin to invalidate_start for consistency Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 5/7] KVM: pfncache: Rename invalidate_start() helper Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 6/7] KVM: Rename mn_* invalidate-related fields to generic ones Takahiro Itazuri
2026-02-26 13:53 ` [RFC PATCH v2 7/7] KVM: pfncache: Invalidate on gmem invalidation and memattr updates Takahiro Itazuri

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=aanCZqjXd0YiSmjR@google.com \
    --to=seanjc@google.com \
    --cc=david@kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=itazur@amazon.com \
    --cc=jackmanb@google.com \
    --cc=kalyazin@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=patrick.roy@campus.lmu.de \
    --cc=pbonzini@redhat.com \
    --cc=pdurrant@amazon.com \
    --cc=tabba@google.com \
    --cc=vkuznets@redhat.com \
    --cc=zulinx86@gmail.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