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] manipulation of RDTSC values in VT xen

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, "Christopher Kanich" <ckanich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] manipulation of RDTSC values in VT xen
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Wed, 1 Feb 2006 08:31:32 -0800
Delivery-date: Wed, 01 Feb 2006 16:42:51 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYnJ7tXcRXuNdUQQAO0yN3Ws3zmJQAACPFAAAhgdEA=
Thread-topic: [Xen-devel] manipulation of RDTSC values in VT xen
Petersson, Mats wrote:
> Chris,
> 

Mats, Hi

Thanks for explaining the VMX stuff ;-) Also please look at "2.6.5
Time-Stamp Counter Offset" in the VT spec, for example.

The RDTSC instruction can be very frequent (e.g. network code in Linux),
and intercepting that instruction could be costly. So we decided to not
intercept but virtualize it using the TSC offsetting.

Some OS directly accesses IA32_TIME_STAMP_COUNTER MSR using RDMSR, and
that will actually cause VM Exit. 

That code below may need more review. If you find something, please let
us know.

Jun
---
Intel Open Source Technology Center

>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>> Christopher Kanich Sent: 01 February 2006 03:51
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: [Xen-devel] manipulation of RDTSC values in VT xen
>> 
>> Hi, I'm currently working with Xen unstable on a VT enabled
>> machine and was wondering if someone could point me to the
>> virtualization point (or somewhere that I might manipulate)
>> the return value of the RDTSC instruction when issued in a
>> guest domain.
> 
> The RDTSC instruction CAN be intercepted, using bit 12 in
> "Processor-based VM-Execution controls", but I believe at the moment
> that this is not being used. This would give EXIT_REASON_RDTSC if this
> is intercepted - this functionality is currently not implemented in
> the vmx.c.
> 
>> 
>> Also, it is my understanding that this value is stored per-VM
>> in the VT architecture, and thus is kept accurate as if the
>> operating system were running solitary on non-VT hardware. Is
>> this correct? I am currently investigating the fidelity of
>> the environment provided by VT Xen to programs run on guest
>> operating systems.
> 
> The current way that TSC handling works is that there's an "Offset" in
> the VMCS that is added to the TSC value when doing a RDTSC. There's a
> few places where TSC offset is written to:
> vmcs.c:vmx_do_launch() - this is where the Virtual machine is started
> the first time.
> io.c:  interrupt_post_injection() - after an interrupt has been
> issued. io.c:  vmx_do_resume() - when a VM is restarted after an
> intercepted event.
> 
> The TSC_OFFSET is a signed value that is added to the actual
> time-stamp counter when a RDTSC instruction is executed - assuming
> bit 3 in Processor-Based Execution control is set, which is the case
> in the code I've currently got, which is a few days old - but I don't
> think there's been a change...
> 
> 
>> 
>> Thanks for any insight you may have to offer, Chris Kanich
>> UCSD Dept. of Computer Science and Engineering
>> 



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

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