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>
|
- [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, (continued)
- [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Nakajima, Jun
- [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Xu, Dongxiao
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Xu, Dongxiao
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- Re: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Keir Fraser
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Zhang, Xiantao
- Re: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Keir Fraser
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR,
Dan Magenheimer <=
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Xu, Dongxiao
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Nakajima, Jun
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- Re: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Jeremy Fitzhardinge
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- Re: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Jeremy Fitzhardinge
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Nakajima, Jun
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Dan Magenheimer
- RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR, Nakajima, Jun
|
|
|