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: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Subject: RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 22 Sep 2009 16:16:12 +0100
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:16:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <bb3075a4-2f3d-4f27-aa08-acce79c8a438@default>
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>
References: <4AB89C7602000078000162B0@xxxxxxxxxxxxxxxxxx> <bb3075a4-2f3d-4f27-aa08-acce79c8a438@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 22.09.09 17:00 >>>
>> >>> 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?)

Of course the expectation would be that the in-memory values are also
tagged with a version.

>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?

No, I don't think that's more risky than writing to kernel memory - Xen
would get a page fault, and skip the write (and return -EFAULT).

>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?

On 32-bit you have 3 registers if you don't want to touch callee
saved ones.
On 64-bit you have 7 of them (considering the differences between
Unix and Windows calling conventions, and hoping there's no third
set in use somewhere).

Jan


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

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