manipulation of RDTSC values in VT xen

manipulation of RDTSC values in VT xen

[Christopher Kanich]

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.

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.

Thanks for any insight you may have to offer,
Chris Kanich
UCSD Dept. of Computer Science and Engineering

RE: manipulation of RDTSC values in VT xen

[Petersson, Mats]

Chris,  

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Christopher Kanich
> Sent: 01 February 2006 03:51
> To: xen-devel@lists.xensource.com
> 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... 

--
Mats

> 
> Thanks for any insight you may have to offer, Chris Kanich 
> UCSD Dept. of Computer Science and Engineering
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

RE: manipulation of RDTSC values in VT xen

[Nakajima, Jun]

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@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>> Christopher Kanich Sent: 01 February 2006 03:51
>> To: xen-devel@lists.xensource.com
>> 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
>> 

RE: manipulation of RDTSC values in VT xen

[Petersson, Mats]

 

> -----Original Message-----
> From: Nakajima, Jun [mailto:jun.nakajima@intel.com] 
> Sent: 01 February 2006 16:32
> To: Petersson, Mats; Christopher Kanich; xen-devel@lists.xensource.com
> Subject: RE: [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.

Well, I had to understand it to make some sense when I took the VMX code
to create the SVM version, so I looked at it a while back, and just had
to refresh my understanding right now. It has changed, but only a little
bit ;-)

--
Mats