[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] More RTC issues with Win2k3
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |