linux-kernel - Re: [KVM TSC trapping / migration 1/2] Add TSC trapping for SVM and VMX

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: <4D268415.5030808@redhat.com>
Date:	Thu, 06 Jan 2011 17:10:13 -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 1/2] Add TSC trapping for SVM and
 VMX

On 01/06/2011 12:38 PM, Alexander Graf wrote:

<snip>
>
> Sure, I'm not saying your patch is bad or goes in the wrong direction. I'd just think it'd be awesome to have an easy way for the guest OS to know that something as crucial as TSC reading speed got changed, hopefully even TSC frequency. Having any form of notification leaves open doors for someone to implement something (think proprietary OSs or out-of-service OSs here). Having no notification leaves us with no choice but taking the penalty and keeping the guest less informed than it has to be.
>    

We do - register kvmclock and check to make sure the version before and 
after time computations to be sure the frequency hasn't changed.

This doesn't even require an interrupt.

>    
>>      
>>>
>>>        
>>>>> Would it make sense to add a kvmclock interrupt to notify the guest of such a change?
>>>>>
>>>>>            
>>>> kvmclock is immune to frequency changes, so it needs no interrupt, it just has a version controlled shared area, which is reset.
>>>>
>>>>          
>>>
>>>        
>>>>>> We indicate to pvclock users that the TSC is being trapped, to allow
>>>>>> avoiding overhead and directly using RDTSCP (only for SVM).  This
>>>>>> optimization is not yet implemented.
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>>> That doesn't sound to me like they're unaffected?
>>>
>>>        
>> On Intel RDTSCP traps along with RDTSC.  This means that you can't have a trapping, constant rate TSC for userspace without also paying the overhead for reading the TSC for kvmclock.  This is not true on SVM, where RDTSCP is a separate trap, allowing optimization.
>>      
> So how does the guest know that something changed when it's migrated from an AMD machine to an Intel machine?
>    

That can and never should happen.  Simply too much state in the guest 
depends on CPU type, different workarounds are enabled for things, and 
even different instruction sets are activated.

There is no reward for the kind of complexity involved.

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/