From: kernel test robot <lkp@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: [sean-jc:x86/kvmclock_vs_tsc 38/38] arch/x86/kernel/smpboot.c:281:2: error: call to undeclared function 'paravirt_sched_clock_start_secondary'; ISO C99 and later do not support implicit function declarations
Date: Sun, 9 Feb 2025 00:15:16 +0800 [thread overview]
Message-ID: <202502090005.YlbsWQ8o-lkp@intel.com> (raw)
tree: https://github.com/sean-jc/linux x86/kvmclock_vs_tsc
head: 4234e8b9df9e1902968f836d9306c026adf43347
commit: 4234e8b9df9e1902968f836d9306c026adf43347 [38/38] x86/paravirt: kvmclock: Setup kvmclock early iff it's sched_clock
config: i386-buildonly-randconfig-004-20250208 (https://download.01.org/0day-ci/archive/20250209/202502090005.YlbsWQ8o-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250209/202502090005.YlbsWQ8o-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/202502090005.YlbsWQ8o-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/x86/kernel/smpboot.c:281:2: error: call to undeclared function 'paravirt_sched_clock_start_secondary'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
281 | paravirt_sched_clock_start_secondary();
| ^
1 error generated.
vim +/paravirt_sched_clock_start_secondary +281 arch/x86/kernel/smpboot.c
228
229 /*
230 * Activate a secondary processor.
231 */
232 static void notrace start_secondary(void *unused)
233 {
234 /*
235 * Don't put *anything* except direct CPU state initialization
236 * before cpu_init(), SMP booting is too fragile that we want to
237 * limit the things done here to the most necessary things.
238 */
239 cr4_init();
240
241 /*
242 * 32-bit specific. 64-bit reaches this code with the correct page
243 * table established. Yet another historical divergence.
244 */
245 if (IS_ENABLED(CONFIG_X86_32)) {
246 /* switch away from the initial page table */
247 load_cr3(swapper_pg_dir);
248 __flush_tlb_all();
249 }
250
251 cpu_init_exception_handling(false);
252
253 /*
254 * Load the microcode before reaching the AP alive synchronization
255 * point below so it is not part of the full per CPU serialized
256 * bringup part when "parallel" bringup is enabled.
257 *
258 * That's even safe when hyperthreading is enabled in the CPU as
259 * the core code starts the primary threads first and leaves the
260 * secondary threads waiting for SIPI. Loading microcode on
261 * physical cores concurrently is a safe operation.
262 *
263 * This covers both the Intel specific issue that concurrent
264 * microcode loading on SMT siblings must be prohibited and the
265 * vendor independent issue`that microcode loading which changes
266 * CPUID, MSRs etc. must be strictly serialized to maintain
267 * software state correctness.
268 */
269 load_ucode_ap();
270
271 /*
272 * Synchronization point with the hotplug core. Sets this CPUs
273 * synchronization state to ALIVE and spin-waits for the control CPU to
274 * release this CPU for further bringup.
275 */
276 cpuhp_ap_sync_alive();
277
278 cpu_init();
279 fpu__init_cpu();
280 rcutree_report_cpu_starting(raw_smp_processor_id());
> 281 paravirt_sched_clock_start_secondary();
282
283 ap_starting();
284
285 /* Check TSC synchronization with the control CPU. */
286 check_tsc_sync_target();
287
288 /*
289 * Calibrate the delay loop after the TSC synchronization check.
290 * This allows to skip the calibration when TSC is synchronized
291 * across sockets.
292 */
293 ap_calibrate_delay();
294
295 speculative_store_bypass_ht_init();
296
297 /*
298 * Lock vector_lock, set CPU online and bring the vector
299 * allocator online. Online must be set with vector_lock held
300 * to prevent a concurrent irq setup/teardown from seeing a
301 * half valid vector space.
302 */
303 lock_vector_lock();
304 set_cpu_online(smp_processor_id(), true);
305 lapic_online();
306 unlock_vector_lock();
307 x86_platform.nmi_init();
308
309 /* enable local interrupts */
310 local_irq_enable();
311
312 x86_cpuinit.setup_percpu_clockev();
313
314 wmb();
315 cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
316 }
317
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2025-02-08 16:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202502090005.YlbsWQ8o-lkp@intel.com \
--to=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=seanjc@google.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 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.