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

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

Message-ID: <20110110135053.GA12991@amt.cnet>
Date:	Mon, 10 Jan 2011 11:50:53 -0200
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Zachary Amsden <zamsden@...hat.com>,
	Juan Quintela <quintela@...hat.com>
Cc:	kvm@...r.kernel.org, Avi Kivity <avi@...hat.com>,
	Glauber Costa <glommer@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [KVM TSC trapping / migration 2/2] Add TSC KHZ MSR

On Fri, Jan 07, 2011 at 10:44:20AM -1000, Zachary Amsden wrote:
> On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
> >On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote:
> >>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.
> >Migration to hosts which do not support the feature can be achieved by
> >saving/restoring the TSC rate + flags in a subsection. A subsection
> >seems more appropriate than an MSR for this.
> 
> Yes, I looked at that, but it looked to me like a subsection was
> intended for an optional feature which MUST be present on the
> destination if the source is using the feature.  This way, newer
> hosts without the feature enabled can migrate to older hosts which
> do not support the feature.

Right. But you can use a subsection to achieve the same effect. Just
consider that the source is not using the feature if you want to migrate
to an older host without support for it. Juan, is there a problem to
use subsections in this fashion?

With the MSR scheme, there is no way for management to enforce support
of the feature on the destination (at least not that i can see). And 
you create an MSR that does not exist on real hardware.

> 
> The TSC rate migration is slightly different; we may wish to migrate
> from a host with the TSC rate feature enabled to a host which does
> not support the TSC rate feature.  This is exactly the current
> behavior, the TSC rate will change on that migration, and I wanted
> to preserve that behavior.  I don't advise that mode of usage, but
> there may be use cases for it and it should be decided by policy,
> not dictated by our feature set.
> 
> That said, I'm happy to remove the MSR if we truly don't want to
> support that mode of usage.

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