| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <202311021159.ppYESBYx-lkp@intel.com>
Date: Thu, 2 Nov 2023 12:03:07 +0800
From: kernel test robot <lkp@...el.com>
To: Paul Durrant <paul@....org>, Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>,
Sean Christopherson <seanjc@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
David Woodhouse <dwmw2@...radead.org>, kvm@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: oe-kbuild-all@...ts.linux.dev
Subject: Re: [PATCH v4] KVM x86/xen: add an override for
PVCLOCK_TSC_STABLE_BIT
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@...el.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
Powered by blists - more mailing lists