WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] xen pv and cpuid

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] xen pv and cpuid
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 28 Oct 2009 09:06:50 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 28 Oct 2009 09:07:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AE6CD62020000780001BF67@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Jan --

For my case, if the set of CPU models that support
this cpuid masking feature is a superset of the set
of CPU models that support TSC Invariant, it would be
helpful.

Any idea if this is true?  If so, an argument can
be made that the TSC Invariant bit should never be
exposed to guests through cpuid (though it may
be made visible through pvcpuid or another
mechanism).

Thanks,
Dan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Tuesday, October 27, 2009 3:37 AM
> To: Dan Magenheimer
> Cc: Xen-Devel (E-mail)
> Subject: Re: [Xen-devel] xen pv and cpuid
> 
> 
> There's one other mechanism in use here - masking CPUID feature bits
> through special vendor MSRs. See the handling of the command line
> options cpuid_mask_{edx,ecx} in xen/arch/x86/cpu/. But this 
> is a global
> mask (i.e. also affecting what Xen itself sees), and isn't 
> available on all
> CPU models...
> 
> Jan
> 
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 26.10.09 18:44 >>>
> Silly x86 question of the day:
> 
> Is it true in a PV domain that there is no way (short of 
> binary translation) to trap a userland cpuid instruction into Xen?
> 
> I found the routine pv_cpuid() in arch/x86/traps.c and 
> assumed that userland cpuid's would find their way into that 
> code, but it appears to not be the case.  After adding some 
> printks and reading the code more closely, I gather that PV 
> OS's somehow get their cpuid instructions replaced with an 
> invalid op so that kernel-land cpuid's do indeed get trapped? 
> Then looking at the Intel SDM I don't see any way to force 
> cpuid at any privilege level to trap (except in an HVM)?
> 
> (If this is all correct, then I am sadly back to needing 
> userland hypercalls :-(
> 
> Thanks,
> Dan
> 
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>