From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: xen-devel@lists.xensource.com, "Dugger,
Donald D" <donald.d.dugger@intel.com>,
"Xu, Dongxiao" <dongxiao.xu@intel.com>,
Keir Fraser <keir.fraser@eu.citrix.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: RE: Saving/Restoring IA32_TSC_AUX MSR
Date: Fri, 11 Dec 2009 10:20:43 -0800 [thread overview]
Message-ID: <4B228D7B.709@goop.org> (raw)
In-Reply-To: <f123c461-16d2-43e1-b8de-0ef90f41cf89@default>
On 12/11/09 07:09, Dan Magenheimer wrote:
>> 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.
>
It will fall back to using the segment limit trick to get vcpu+vnode
info if rdtscp isn't available, so they'll get the info either way.
It's not clear how many apps make good use of the numa node info, but
presumably some do. So long as the virtual numa info bears some vague
resemblance to the real topology then they could still make use of it in
a Xen domain. Whether or not Xen currently implements that is a
separate question.
However, the vcpu number is definitely useful to usermode apps, so they
can get some idea how they're moved between (v)cpus. I don't think it
will matter to them that it isn't pcpu.
J
next prev parent reply other threads:[~2009-12-11 18:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 16:41 Saving/Restoring IA32_TSC_AUX MSR Nakajima, Jun
2009-12-09 16:59 ` Dan Magenheimer
2009-12-09 17:07 ` Nakajima, Jun
2009-12-09 17:22 ` Dan Magenheimer
2009-12-10 11:21 ` Xu, Dongxiao
2009-12-10 15:49 ` Dan Magenheimer
2009-12-11 1:22 ` Xu, Dongxiao
2009-12-11 2:00 ` Dan Magenheimer
2009-12-11 8:03 ` Keir Fraser
2009-12-11 8:43 ` Zhang, Xiantao
2009-12-11 9:22 ` Keir Fraser
2009-12-11 15:09 ` Dan Magenheimer
2009-12-11 15:28 ` Xu, Dongxiao
2009-12-11 16:12 ` Dan Magenheimer
2009-12-11 18:38 ` Nakajima, Jun
2009-12-11 19:46 ` Dan Magenheimer
2009-12-11 18:20 ` Jeremy Fitzhardinge [this message]
2009-12-11 18:35 ` Dan Magenheimer
2009-12-11 18:50 ` Jeremy Fitzhardinge
2009-12-11 19:29 ` Nakajima, Jun
2009-12-11 22:23 ` Dan Magenheimer
2009-12-11 22:58 ` Nakajima, Jun
2009-12-11 23:30 ` Dan Magenheimer
2009-12-11 23:44 ` Xu, Dongxiao
2009-12-12 0:09 ` Dan Magenheimer
2009-12-12 0:30 ` Xu, Dongxiao
2009-12-13 9:17 ` Zhang, Xiantao
2009-12-13 18:06 ` Dan Magenheimer
2009-12-13 18:59 ` Jeremy Fitzhardinge
2009-12-14 6:33 ` Xu, Dongxiao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B228D7B.709@goop.org \
--to=jeremy@goop.org \
--cc=dan.magenheimer@oracle.com \
--cc=donald.d.dugger@intel.com \
--cc=dongxiao.xu@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
--cc=xiantao.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.