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 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.