arkady wrote:When I didn't move the mouse, a loop took 2178 cycles/each to execute - 0,0197s in whole (and as an 'anomaly': 2241 cyc.every 32nd time and 2300-2400 cyc.-8 times in all 16.384 passes - why? I don't know).
For the small changes of cycles when not moving the mouse: ( 2178, 2241, 2300-2400 ): The CPU internal core usually tries to execute instructions out of order in a random fashion, and tries to re-order them. however tight loops, or small differences between execution of each micro-op in the core, micro-op syncronization issues, may create resonances ( couldn't find a better word
) which you observe every 8-32-64 loops. therefore cycles per instructions ( and TSC ) is usually not unique. I guess this is why you get like 2241 clocks each 32nd time and etc. I think that would explain the "anomaly"
arkady wrote:
When I was moving the mouse, I noticed that 6 times a loop was executing approx. 1.145.000 cycles - over 500 times longer than usual! This time all passes took 0,0235s to execute. I think SMIs may be responsible for these differences, or maybe not...?
Most probably it is SMI
Less ( but not zero ) probably, since USB mouse will try to use the system BUS when you move it, to try sending interrupts or etc... this may be effecting the internal CPU core. but it wouldn't take 500 times longer
it is most probably SMI.
Cemre, as you said, seems like SMI handler can modify TSC and prevent us from knowing it was ever triggered. But I wonder - what would be the purpose of that? AFAIK, we can both read 'the original' SMI handler and 'modify' it if this wasn't disabled by BIOS. So why would the designers want to hide the fact that the handler was executed? Another question is why we would like to know that it was ever triggered?
Cemre wrote:
Microsoft doesn't want people to use SMI for hardware virtualizing because some boards come with buggy BIOS that corrupt PCI, ACPI or USB state to handle USBtoPS/2 mouse, which confuses windows and worst case, brings it down. But well who listens to what microsoft says
I think board manufacturers are worried about microsoft. let's think of a ( rare ) case where microsoft IS able to detect an SMI by reading TSC before and after an assembly "out" or "in" instruction ( or by some other detection method ). and if the system crashes afterwards, this will be reflected to system logs, microsoft can simply blame the board manufacturer for the crash to come clean out of it.
I know it is a rare issue but microsoft is really searching for things like that nowadays ( since windows has a bad crash publicity
) so that everyone doesn't always blame a crash to windows. They would say, "buy a microsoft USB mouse"
or "don't use the mouse in PS/2 mode and retry"
even, change/update your motherboard/bios. So the board manufacturers are trying to make windows unable to detect it. ( legal issues )
Another one might be; "to be able to recover from a known BIOS bug". if microsoft or an OS developper knows that a certain BIOS type causes a PCI or USB state change when it tries to simulate USBtoPS/2 mouse, they might simply try to recover that state by rewriting PCI or USB registers after receiving the mouse input.
USBtoPS/2 mouse simulation is becoming one of the most used cases of SMM those days, and it is really prone to errors on the USB bus, I heard that some people are unable to use their USB wireless dongles, or Bluetooth dongles when they enable PS/2 mode.
Best wishes.
...and a potential threat to security, as some say - I think only a potential one because I haven't heard of anyone ever misusing SMM. Viruses, worms and alike are much more simple to spread after all.