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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B8EAB0F.3000104@goop.org>
Date:	Wed, 03 Mar 2010 10:31:43 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Sheng Yang <sheng@...ux.intel.com>
CC:	Keir Fraser <keir.fraser@...citrix.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Ian Pratt <Ian.Pratt@...citrix.com>,
	linux-kernel@...r.kernel.org,
	xen-devel <xen-devel@...ts.xensource.com>,
	Ian Campbell <Ian.Campbell@...rix.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>
Subject: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/