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: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@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 11:46:41 -0800 (PST)
Cc: "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
Delivery-date: Fri, 11 Dec 2009 11:49:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C08B02B7E75BDA4BBAA8F1648BDCC20D56F9D4D1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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
> It's possible, and the way guest NUMA supposed to be. We are 
> working on that.

I'd be very interested in learning more about your plans.

> -----Original Message-----
> From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx]
> Sent: Friday, December 11, 2009 11:38 AM
> To: Dan Magenheimer; Xu, Dongxiao; Keir Fraser; Zhang, Xiantao;
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Dugger, Donald D
> Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
> 
> 
> Dan Magenheimer wrote on Fri, 11 Dec 2009 at 08:12:00:
> 
> >>> 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.
> >> 
> >> This is depend on how the node info is virtualized.
> >> If the virtual node could reflect the physical
> >> node info, what rdtscp returns is valuable to applications.
> > 
> > If it is possible to ensure that the cpu/node info
> > is virtualized so that TSC_AUX always correctly provides the
> > information needed by apps, I agree this would be
> > valuable.  I don't see how this is possible, but maybe
> > you have some creative ideas?
> 
> It's possible, and the way guest NUMA supposed to be. We are 
> working on that.
> 
> Jun
> ___
> Intel Open Source Technology Center
> 
> 
> 
> 
> _______________________________________________
> 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>