[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 5/7] xen: Make event channel work with PV extension of HVM



On 03/01/2010 09:48 PM, Sheng Yang wrote:
Presumably even if we don't have PV_EVTCHN available/enabled, the Xen
clocksource would be available for getting time?
I think currently Xen pv clocksource and clockevent are binding... Not sure if
a single line "clocksource_register(&xen_clocksource)" can work. I would give
it a try, maybe add a new PV feature.

There should be no strong binding between them, but there may be some sloppy assumptions in xen/time.c which should be fixed. Linux itself treats clocksources and eventsources as completely distinct entities, and doesn't assume they're running on the same timebase (for example).

Having a PV clocksource even if the timer interrupts are emulated would make sense and be useful.

        xen_setup_vcpu_info_placement();
   }
@@ -480,3 +487,138 @@ void __init xen_smp_init(void)
        xen_fill_possible_map();
        xen_init_spinlocks();
   }
+
+static __cpuinit void xen_hvm_pv_start_secondary(void)
+{
+       int cpu = smp_processor_id();
+
+       cpu_init();
+       touch_nmi_watchdog();
+       preempt_disable();
+
+       /* otherwise gcc will move up smp_processor_id before the cpu_init */
+       barrier();
+       /*
+        * Check TSC synchronization with the BSP:
+        */
+       check_tsc_sync_target();
+
+       /* Done in smp_callin(), move it here */
+       set_mtrr_aps_delayed_init();
+       smp_store_cpu_info(cpu);
+
+       /* This must be done before setting cpu_online_mask */
+       set_cpu_sibling_map(cpu);
+       wmb();
+
+       set_cpu_online(smp_processor_id(), true);
+       per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
+
+       /* enable local interrupts */
+       local_irq_enable();
+
+       xen_setup_cpu_clockevents();
How much of this is necessary?  At this point, isn't CPU bringup the
same as PV?
Xen_enable_sysenter/syscall is not needed for this. And we have a TSC sync
here - but it seems unnecessary for PV. But set_mtrr_aps_delayed_init() is
needed. Reuse the cpu_bring_up() is fine?

Doesn't Xen arrange for the tscs to be synced anyway?

Is the MMUEXT_TLB_FLUSH/INVLPG_MULTI hypercall not currently available
to HVM?
I 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
for it.

I see.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.