Re: [Xen-devel] More RTC issues with Win2k3

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.13 at 15:37, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/09/13 13:44, Jan Beulich wrote:
>> Not knowing what precise data Xentrace produces - does that include
>> any timing information? If so, what's the smallest delta between two
>> of these REG_C reads?
> 
> Yes.  Here is a larger sample:
> 
> ]  2.862018629  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>    2.862018629  d98v0 io write port 70 val c
> ]  2.862019461  d98v0 vmentry cycles 1996
> ]  2.862019936  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>    2.862019936  d98v0 io read port 71 val c0
> ]  2.862021275  d98v0 vmentry cycles 3214
> ]  2.862021752  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>    2.862021752  d98v0 io write port 70 val c
> ]  2.862022560  d98v0 vmentry cycles 1938
> ]  2.862023068  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>    2.862023068  d98v0 io read port 71 val c0
> ]  2.862024410  d98v0 vmentry cycles 3220
> ]  2.862024886  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>    2.862024886  d98v0 io write port 70 val c
> ]  2.862025735  d98v0 vmentry cycles 2037
> ]  2.862026207  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>    2.862026207  d98v0 io read port 71 val c0
> ]  2.862027537  d98v0 vmentry cycles 3190
> ]  2.862028012  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>    2.862028012  d98v0 io write port 70 val c
> ]  2.862028854  d98v0 vmentry cycles 2021
> ]  2.862029322  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>    2.862029322  d98v0 io read port 71 val c0
> ]  2.862030668  d98v0 vmentry cycles 3232
> ]  2.862031145  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>    2.862031145  d98v0 io write port 70 val c
> ]  2.862031954  d98v0 vmentry cycles 1941
> ]  2.862032462  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>    2.862032462  d98v0 io read port 71 val c0
> ]  2.862033762  d98v0 vmentry cycles 3118
> ]  2.862034233  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814176
>    2.862034233  d98v0 io write port 70 val c
> ]  2.862035082  d98v0 vmentry cycles 2036
> ]  2.862035558  d98v0 vmexit exit_reason IO_INSTRUCTION eip fffff80000814177
>    2.862035558  d98v0 io read port 71 val c0
> ]  2.862036937  d98v0 vmentry cycles 3309
> 
> George will know for certain, but as far as I am aware, the timestamp
> column is calculated from raw TSC counter values embedded in the trace
> records.

Given how close the entries are, it doesn't even matter whether
that's TSC ticks or nanoseconds - they're definitely way too close
together to represent a state that should be permitted to get
into with a periodic timer tick of 64Hz.

> As an easy starting point of reference, I will completely disable
> writing the WAET table to see whether that makes a difference.

That's going to be fruitless afaict - as said before, the early RTC
interrupt handler they install doesn't even look at the WAET info.

What you will want to check is the rate at which
rtc_periodic_interrupt() gets invoked in this case, as that's the only
place that can set RTC_PF (which you observe constantly set), and
how this (presumably) ends up being much faster than intended
(i.e. presumably some issue in pt_update_irq()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel