linux-kernel - Re: [KVM TSC trapping / migration 2/2] Add TSC KHZ MSR

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]

Date:	Thu, 06 Jan 2011 10:34:57 -1000
From:	Zachary Amsden <zamsden@...hat.com>
To:	Alexander Graf <agraf@...e.de>
CC:	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [KVM TSC trapping / migration 2/2] Add TSC KHZ MSR

On 01/06/2011 01:40 AM, Alexander Graf wrote:
> On 06.01.2011, at 12:27, Zachary Amsden wrote:
>
>    
>> On 01/06/2011 12:34 AM, Alexander Graf wrote:
>>      
>>> Am 06.01.2011 um 11:10 schrieb Zachary Amsden<zamsden@...hat.com>:
>>>
>>>
>>>        
>>>> Use an MSR to allow "soft" migration to hosts which do not support
>>>> TSC trapping.  Rather than make this a required element of any
>>>> migration protocol, we allow the TSC rate to be exported as a data
>>>> field (useful in its own right), but we also allow a one time write
>>>> of the MSR during VM creation.  The result is that for the common
>>>> use case, no protocol change is required to communicate TSC rate
>>>> to the receiving host.
>>>>
>>>> This allows administrative tools to configure migration policy
>>>> as they see appropriate.  Rather than dictate this policy with the
>>>> KVM implementation, we properly allow migration to hosts which both
>>>> do and do not support setting of the TSC rate on the receiving end.
>>>> If it is wished to not support migration to a host which lacks
>>>> support for the TSC rate feature, that can be coordinated externally.
>>>>
>>>>          
>>> Isn't there a real hw equivalent of such a register? It might make more sense to just implement that then.
>>>
>>>
>>>        
>> Unfortunately, no.
>>      
> Bleks. I couldn't find anything in AMD documentation either. Intel documentation is usually hard to find and incomplete anyways, so maybe something's hiding there - but if it's hidden so well it's no use to implement either.
>    

While it makes perfect logical sense to us software people, from a 
hardware perspective it is ridiculous.  There is no signal input to the 
processor which can be counted and returned by a "CPU frequency MSR".  
The CPU frequency is simply what the CPU is clocked at.  And you can't 
burn it onto the die (think of overclocking), unless you have your own 
internal reference oscillator.

No, a CPU frequency MSR is impossible to implement sensibly in hardware 
because

1) if you have an internal clock, you have cross-CPU drift and can't 
easily share a common bus.
2) if you have an external clock, you have no way to measure the 
frequency of it without an internal reference, which again will vary, 
leading to different measured frequency on each CPU.

The only thing that sort of makes sense is a one-time writable MSR that 
is programmed by the BIOS to return the CPU frequency, as retrieved from 
the chipset.  This is merely a convenience for software people who can't 
be bothered to query the chipset directly or measure against a reference 
clock.

So as much as we'd like it, it really does make little sense from a 
hardware perspective.

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