From: kernel test robot <lkp@intel.com>
To: Paul Durrant <paul@xen.org>, Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Sean Christopherson <seanjc@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
David Woodhouse <dwmw2@infradead.org>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH v4] KVM x86/xen: add an override for PVCLOCK_TSC_STABLE_BIT
Date: Thu, 2 Nov 2023 12:03:07 +0800 [thread overview]
Message-ID: <202311021159.ppYESBYx-lkp@intel.com> (raw)
In-Reply-To: <20231101183032.1498211-1-paul@xen.org>
Hi Paul,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 35dcbd9e47035f98f3910ae420bf10892c9bdc99]
url: https://github.com/intel-lab-lkp/linux/commits/Paul-Durrant/KVM-x86-xen-add-an-override-for-PVCLOCK_TSC_STABLE_BIT/20231102-034122
base: 35dcbd9e47035f98f3910ae420bf10892c9bdc99
patch link: https://lore.kernel.org/r/20231101183032.1498211-1-paul%40xen.org
patch subject: [PATCH v4] KVM x86/xen: add an override for PVCLOCK_TSC_STABLE_BIT
config: i386-randconfig-013-20231102 (https://download.01.org/0day-ci/archive/20231102/202311021159.ppYESBYx-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231102/202311021159.ppYESBYx-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311021159.ppYESBYx-lkp@intel.com/
All warnings (new ones prefixed by >>):
arch/x86/kvm/x86.c: In function 'kvm_guest_time_update':
>> arch/x86/kvm/x86.c:3176:14: warning: unused variable 'xen_pvclock_tsc_unstable' [-Wunused-variable]
3176 | bool xen_pvclock_tsc_unstable =
| ^~~~~~~~~~~~~~~~~~~~~~~~
vim +/xen_pvclock_tsc_unstable +3176 arch/x86/kvm/x86.c
3158
3159 static int kvm_guest_time_update(struct kvm_vcpu *v)
3160 {
3161 unsigned long flags, tgt_tsc_khz;
3162 unsigned seq;
3163 struct kvm_vcpu_arch *vcpu = &v->arch;
3164 struct kvm_arch *ka = &v->kvm->arch;
3165 s64 kernel_ns;
3166 u64 tsc_timestamp, host_tsc;
3167 u8 pvclock_flags;
3168 bool use_master_clock;
3169
3170 /*
3171 * For Xen guests we may need to override PVCLOCK_TSC_STABLE_BIT as unless
3172 * explicitly told to use TSC as its clocksource Xen will not set this bit.
3173 * This default behaviour led to bugs in some guest kernels which cause
3174 * problems if they observe PVCLOCK_TSC_STABLE_BIT in the pvclock flags.
3175 */
> 3176 bool xen_pvclock_tsc_unstable =
3177 ka->xen_hvm_config.flags & KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE;
3178
3179 kernel_ns = 0;
3180 host_tsc = 0;
3181
3182 /*
3183 * If the host uses TSC clock, then passthrough TSC as stable
3184 * to the guest.
3185 */
3186 do {
3187 seq = read_seqcount_begin(&ka->pvclock_sc);
3188 use_master_clock = ka->use_master_clock;
3189 if (use_master_clock) {
3190 host_tsc = ka->master_cycle_now;
3191 kernel_ns = ka->master_kernel_ns;
3192 }
3193 } while (read_seqcount_retry(&ka->pvclock_sc, seq));
3194
3195 /* Keep irq disabled to prevent changes to the clock */
3196 local_irq_save(flags);
3197 tgt_tsc_khz = get_cpu_tsc_khz();
3198 if (unlikely(tgt_tsc_khz == 0)) {
3199 local_irq_restore(flags);
3200 kvm_make_request(KVM_REQ_CLOCK_UPDATE, v);
3201 return 1;
3202 }
3203 if (!use_master_clock) {
3204 host_tsc = rdtsc();
3205 kernel_ns = get_kvmclock_base_ns();
3206 }
3207
3208 tsc_timestamp = kvm_read_l1_tsc(v, host_tsc);
3209
3210 /*
3211 * We may have to catch up the TSC to match elapsed wall clock
3212 * time for two reasons, even if kvmclock is used.
3213 * 1) CPU could have been running below the maximum TSC rate
3214 * 2) Broken TSC compensation resets the base at each VCPU
3215 * entry to avoid unknown leaps of TSC even when running
3216 * again on the same CPU. This may cause apparent elapsed
3217 * time to disappear, and the guest to stand still or run
3218 * very slowly.
3219 */
3220 if (vcpu->tsc_catchup) {
3221 u64 tsc = compute_guest_tsc(v, kernel_ns);
3222 if (tsc > tsc_timestamp) {
3223 adjust_tsc_offset_guest(v, tsc - tsc_timestamp);
3224 tsc_timestamp = tsc;
3225 }
3226 }
3227
3228 local_irq_restore(flags);
3229
3230 /* With all the info we got, fill in the values */
3231
3232 if (kvm_caps.has_tsc_control)
3233 tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz,
3234 v->arch.l1_tsc_scaling_ratio);
3235
3236 if (unlikely(vcpu->hw_tsc_khz != tgt_tsc_khz)) {
3237 kvm_get_time_scale(NSEC_PER_SEC, tgt_tsc_khz * 1000LL,
3238 &vcpu->hv_clock.tsc_shift,
3239 &vcpu->hv_clock.tsc_to_system_mul);
3240 vcpu->hw_tsc_khz = tgt_tsc_khz;
3241 kvm_xen_update_tsc_info(v);
3242 }
3243
3244 vcpu->hv_clock.tsc_timestamp = tsc_timestamp;
3245 vcpu->hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
3246 vcpu->last_guest_tsc = tsc_timestamp;
3247
3248 /* If the host uses TSC clocksource, then it is stable */
3249 pvclock_flags = 0;
3250 if (use_master_clock)
3251 pvclock_flags |= PVCLOCK_TSC_STABLE_BIT;
3252
3253 vcpu->hv_clock.flags = pvclock_flags;
3254
3255 if (vcpu->pv_time.active)
3256 kvm_setup_guest_pvclock(v, &vcpu->pv_time, 0, false);
3257 #ifdef CONFIG_KVM_XEN
3258 if (vcpu->xen.vcpu_info_cache.active)
3259 kvm_setup_guest_pvclock(v, &vcpu->xen.vcpu_info_cache,
3260 offsetof(struct compat_vcpu_info, time),
3261 xen_pvclock_tsc_unstable);
3262 if (vcpu->xen.vcpu_time_info_cache.active)
3263 kvm_setup_guest_pvclock(v, &vcpu->xen.vcpu_time_info_cache, 0,
3264 xen_pvclock_tsc_unstable);
3265 #endif
3266 kvm_hv_setup_tsc_page(v->kvm, &vcpu->hv_clock);
3267 return 0;
3268 }
3269
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
prev parent reply other threads:[~2023-11-02 4:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-01 18:30 [PATCH v4] KVM x86/xen: add an override for PVCLOCK_TSC_STABLE_BIT Paul Durrant
2023-11-02 4:03 ` kernel test robot [this message]
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=202311021159.ppYESBYx-lkp@intel.com \
--to=lkp@intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).