From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] pvcpuid: mask TSC invariant bit for various circumstances Date: Tue, 27 Oct 2009 20:58:47 +0000 Message-ID: References: <1d7deb17-adc7-4b19-8727-adcde3080e72@default> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1d7deb17-adc7-4b19-8727-adcde3080e72@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer , "Xen-Devel (E-mail)" List-Id: xen-devel@lists.xenproject.org On 27/10/2009 20:40, "Dan Magenheimer" wrote: > The hacky part is my attempt for > the same cpuid bit (Invariant TSC) to have slightly > different interpretations depending on whether it is > physical (cpuid) or virtualized (pvcpuid) How are you overloading it? According to your last patch you would only make that bit visible to the guest when the TSC is invariant, and will remain invariant (due to migration being disabled). That's within native semantics of that bit, right? > So are you suggesting that the best mechanism for > "userland hypercalls" is special reserved cpuid leaves? If you want to provide 'feature flags' and other such info to the guest, it seems a pretty reasonable approach, since it already exists and that's what it's intended for. There may be other things you want to do for which it is not an appropriate solution, but everything so far seems handleable via it. > Also, any comments on the meat of my last reply? Looked pretty complicated to me. Can't say as I fully understand it. -- Keir