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

[Jeremy Fitzhardinge <jeremy@goop.org>]

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