linux-kernel - Re: [Xen-devel] [PATCH] xen-time: decreasing the rating of the xen clocksource below that of the tsc clocksource for dom0's

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 for Android: free password hash cracker in your pocket

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

Message-ID: <54B53CDD.7070400@oracle.com>
Date:	Tue, 13 Jan 2015 10:42:21 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>,
	Imre Palik <imrep.amz@...il.com>,
	xen-devel@...ts.xenproject.org
CC:	"Palik, Imre" <imrep@...zon.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Anthony Liguori <aliguori@...zon.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCH] xen-time: decreasing the rating of the xen
 clocksource below that of the tsc clocksource for dom0's

On 01/13/2015 04:52 AM, David Vrabel wrote:
> On 13/01/15 08:14, Imre Palik wrote:
>> From: "Palik, Imre" <imrep@...zon.de>
>>
>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
>> be used) instead of the Xen clocksource should not cause any issues, as
>> Dom0 VMs never live-migrated.  The TSC clocksource is somewhat more
>> efficient than the Xen paravirtualised clocksource, thus it should have
>> higher rating.
>>
>> This patch decreases the rating of the Xen clocksource in Dom0s to 275.
>> Which is half-way between the rating of the TSC clocksource (300) and the
>> hpet clocksource (250).
> I'm happy with this but would like to see acks from those who objected
> to v1.
>
> David
>
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -487,6 +487,10 @@ static void __init xen_time_init(void)
>>   	int cpu = smp_processor_id();
>>   	struct timespec tp;
>>   
>> +	/* As Dom0 is never moved, no penalty on using TSC there */

Again, why not any PV guest with TSC_MODE_NEVER_EMULATE?

And I am not sure I understood the argument about unsynchronized TSCs. 
You mentioned you can't find a platform to test on. I think you may be 
able to unsynchronize TSCs by writing something to MSR 0x10 early during 
Xen boot and then migrate dom0's vcpu to that pcpu later (making sure 
this vcpu was not running there while dom0 was booting)

-boris

>> +	if (xen_initial_domain())
>> +		xen_clocksource.rating = 275;
>> +
>>   	clocksource_register_hz(&xen_clocksource, NSEC_PER_SEC);
>>   
>>   	if (HYPERVISOR_vcpu_op(VCPUOP_stop_periodic_timer, cpu, NULL) == 0) {
>>

--
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/