WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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

<Prev in Thread] Current Thread [Next in Thread>