|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 5/7] xen: Make event channel work with PV extensi
To: |
Sheng Yang <sheng@xxxxxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel] [PATCH 5/7] xen: Make event channel work with PV extension of HVM |
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Date: |
Wed, 03 Mar 2010 10:31:43 -0800 |
Cc: |
xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
Delivery-date: |
Wed, 03 Mar 2010 10:32:26 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<201003021348.06360.sheng@xxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<1267436315-24486-1-git-send-email-sheng@xxxxxxxxxxxxxxx> <1267436315-24486-6-git-send-email-sheng@xxxxxxxxxxxxxxx> <4B8C6C0D.3070005@xxxxxxxx> <201003021348.06360.sheng@xxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1 |
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
|
|
|
|
|