Hi David, kernel test robot noticed the following build errors: [auto build test ERROR on kvm/queue] [also build test ERROR on mst-vhost/linux-next linus/master v6.6-rc7] [cannot apply to kvm/linux-next next-20231027] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/David-Woodhouse/KVM-x86-xen-improve-accuracy-of-Xen-timers/20231028-020037 base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue patch link: https://lore.kernel.org/r/b5a974bdc330be91c2356f5bb2cc68ef1cc7ed40.camel%40infradead.org patch subject: [PATCH] KVM: x86/xen: improve accuracy of Xen timers config: i386-randconfig-014-20231029 (https://download.01.org/0day-ci/archive/20231029/202310291835.JpCiqj3X-lkp@xxxxxxxxx/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/20231029/202310291835.JpCiqj3X-lkp@xxxxxxxxx/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@xxxxxxxxx> | Closes: https://lore.kernel.org/oe-kbuild-all/202310291835.JpCiqj3X-lkp@xxxxxxxxx/ All errors (new ones prefixed by >>): ld: arch/x86/kvm/xen.o: in function `kvm_xen_start_timer': >> arch/x86/kvm/xen.c:171: undefined reference to `kvm_get_monotonic_and_clockread' vim +171 arch/x86/kvm/xen.c 147 148 static void kvm_xen_start_timer(struct kvm_vcpu *vcpu, u64 guest_abs, 149 bool linux_wa) 150 { 151 uint64_t guest_now, host_tsc, guest_tsc; 152 int64_t kernel_now, delta; 153 154 /* 155 * The guest provides the requested timeout in absolute nanoseconds 156 * of the KVM clock — as *it* sees it, based on the scaled TSC and 157 * the pvclock information provided by KVM. 158 * 159 * The kernel doesn't support hrtimers based on CLOCK_MONOTONIC_RAW 160 * so use CLOCK_MONOTONIC. In the timescales covered by timers, the 161 * difference won't matter much as there is no cumulative effect. 162 * 163 * Calculate the time for some arbitrary point in time around "now" 164 * in terms of both kvmclock and CLOCK_MONOTONIC. Calculate the 165 * delta between the kvmclock "now" value and the guest's requested 166 * timeout, apply the "Linux workaround" described below, and add 167 * the resulting delta to the CLOCK_MONOTONIC "now" value, to get 168 * the absolute CLOCK_MONOTONIC time at which the timer should 169 * fire. 170 */ > 171 if (!kvm_get_monotonic_and_clockread(&kernel_now, &host_tsc)) { 172 /* 173 * Even in this case, don't fall back to get_kvmclock_ns() 174 * because it's broken; it has a systemic error in its 175 * results because it scales directly from host TSC to 176 * nanoseconds, and doesn't scale first to guest TSC and 177 * *then* to nanoseconds as the guest does. 178 * 179 * There is a small error introduced here because time 180 * continues to elapse between the ktime_get() and the 181 * subsequent rdtsc(). 182 */ 183 kernel_now = ktime_get(); /* This is CLOCK_MONOTONIC */ 184 host_tsc = rdtsc(); 185 } 186 187 /* Calculate the guest kvmclock as the guest would do it. */ 188 guest_tsc = kvm_read_l1_tsc(vcpu, host_tsc); 189 guest_now = __pvclock_read_cycles(&vcpu->arch.hv_clock, guest_tsc); 190 delta = guest_abs - guest_now; 191 192 /* Xen has a 'Linux workaround' in do_set_timer_op() which 193 * checks for negative absolute timeout values (caused by 194 * integer overflow), and for values about 13 days in the 195 * future (2^50ns) which would be caused by jiffies 196 * overflow. For those cases, it sets the timeout 100ms in 197 * the future (not *too* soon, since if a guest really did 198 * set a long timeout on purpose we don't want to keep 199 * churning CPU time by waking it up). 200 */ 201 if (linux_wa) { 202 if ((unlikely((int64_t)guest_abs < 0 || 203 (delta > 0 && (uint32_t) (delta >> 50) != 0)))) { 204 delta = 100 * NSEC_PER_MSEC; 205 guest_abs = guest_now + delta; 206 } 207 } 208 209 atomic_set(&vcpu->arch.xen.timer_pending, 0); 210 vcpu->arch.xen.timer_expires = guest_abs; 211 212 if (delta <= 0) { 213 xen_timer_callback(&vcpu->arch.xen.timer); 214 } else { 215 hrtimer_start(&vcpu->arch.xen.timer, 216 ktime_add_ns(kernel_now, delta), 217 HRTIMER_MODE_ABS_HARD); 218 } 219 } 220 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
