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] RE: Saving/Restoring IA32_TSC_AUX MSR

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 11 Dec 2009 07:09:39 -0800 (PST)
Cc: "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
Delivery-date: Fri, 11 Dec 2009 07:13:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C747BFC8.4224%keir.fraser@xxxxxxxxxxxxx>
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
> As I know, RDTSCP can used to implment fast vgetcpu in 
> newer Linux kernel.

Yes, but code which uses fast vgetcpu is expecting
to get physical cpu and physical node number.  Since
an HVM guest OS only has access to virtual cpu and
virtual node number, the information written to TSC_AUX
by a guest OS is misleading and may silently break any
userland code that assumes it is getting physical
information.

I continue to think this is a bad idea and, to use Keir's
words, is "Supporting CPU instructions just because
they're there".

But, if I am overruled, I'd like to see some measurement
of the cycle cost for writing to TSC_AUX.  Since
Linux only writes it once at __cpuinit time, I wouldn't
be surprised to find out that it is horribly slow
and adding it to every context switch would be slowing
down all users of Xen for a handful of applications --
that are getting incorrect information (vcpu vs pcpu)
anyway.

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Friday, December 11, 2009 2:22 AM
> To: Zhang, Xiantao; Dan Magenheimer; Xu, Dongxiao; Nakajima, Jun;
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Dugger, Donald D
> Subject: Re: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
> 
> 
> On 11/12/2009 08:43, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
> 
> >> The question has to be: what win do we get for faithful
> >> virtualisation of RDTSCP in a virtualised environment? 
> Supporting CPU
> >> instructions just because they're there is not a useful effort.
> > 
> > As I know, RDTSCP can used to implment fast vgetcpu in 
> newer Linux kernel.
> > Current node and cpu info is saved in the MSR, and 
> applications or libraries
> > can get this info at ring3 through this instruction. If enable this
> > instruction for vmx non-root mode,  it should benefit these 
> kernels I think.
> 
> Sounds reasonable. Obviously this will be incompatible with 
> pvrdtscp, but
> the latter is off by default so this isn't a too serious 
> problem I think.
> Pvrdtscp will simply trump ordinary RDTSCP emulation when it 
> is enabled.
> 
> You can put your meddling with TSC_AUX MSR in the context-switch path,
> regradless of whether pvrdtscp's stays in __update_vcpu_system_time().
> 
> In short: have at it.
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

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

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