Presumably even if we don't have PV_EVTCHN available/enabled, the XenI think currently Xen pv clocksource and clockevent are binding... Not sure if
clocksource would be available for getting time?
a single line "clocksource_register(&xen_clocksource)" can work. I would give
it a try, maybe add a new PV feature.
Xen_enable_sysenter/syscall is not needed for this. And we have a TSC syncxen_setup_vcpu_info_placement();How much of this is necessary? At this point, isn't CPU bringup the
@@ -480,3 +487,138 @@ void __init xen_smp_init(void)
+static __cpuinit void xen_hvm_pv_start_secondary(void)
+ int cpu = smp_processor_id();
+ /* otherwise gcc will move up smp_processor_id before the cpu_init */
+ * Check TSC synchronization with the BSP:
+ /* Done in smp_callin(), move it here */
+ /* This must be done before setting cpu_online_mask */
+ set_cpu_online(smp_processor_id(), true);
+ per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
+ /* enable local interrupts */
same as PV?
here - but it seems unnecessary for PV. But set_mtrr_aps_delayed_init() is
needed. Reuse the cpu_bring_up() is fine?
Is the MMUEXT_TLB_FLUSH/INVLPG_MULTI hypercall not currently availableI think they are different. These hypercalls flushed native's TLB, but HVM
want to flush guest one, especially when using shadow, HVM need do something