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] rdtscP and xen (and maybe the app-tsc answer I've been l

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 22 Sep 2009 08:00:04 -0700 (PDT)
Cc: kurt.hackel@xxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 22 Sep 2009 08:00:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB89C7602000078000162B0@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
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 22.09.09 01:29 >>>
> >Yes, I neglected an important pre-condition.  ASSUME the first
> >rdtscp on pcpu-A gets a version mismatch so that it must fetch
> >the parameters again.  Then: the vcpu switches pcpu TWICE
> >from pcpu-A to pcpu-B and back to pcpu-A and does rdtscp
> >each time on pcpu-A but reads one or more pvclock parameters
> >(that are too big to be encoded in TSC_AUX) on pcpu-B.
> 
> This fundamentally depends on how the pvclock parameters are being
> read: While app-accessible MSRs inherently require each of 
> the necessary
> RDMSRs to be executed on the correct {p,v}CPU (unless you encode the
> CPU number in the RDMSR input), an app accessible shared memory region
> wouldn't have that property.

Hmmm...  I think a shared memory region still does have that property.
To avoid any possibility of a race, there must be a way to atomically
fetch the full set of values:

{ tsc, tsc_aux, pvclock parameters }.

(How many bits total in pvclock parameters?)

Jeremy's proposal of a userland hypercall ("get_new_pvclock_info")
can do that, but I don't see how a shared memory region can.
But a userland hypercall that writes to userland memory seems
risky.  An app can mmap memory, if it fails to do so (either
accidentally or maliciously), bad things can happen, correct?

Pardon my x86 ignorance again:  If we define a userland rdmsr,
it could overwrite more than just EDX:EAX.  If it overwrites
all registers that can safely be changed by the calling
convention, which registers (how many bits) can it "return"?
I suspect this isn't enough for 32-bit guests, but maybe
it is for 64-bit guests?

Dan

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

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