Why would you?
The reason the single run completed successfully was apparently that no
actual virtualization event triggered, so it actually accessed the
hardware successfully and without any real slowdown. As shown also by the
fact that the actual frequency was correct at the end.
The ones that failed presumably all had interrupts that happened in the
VM, which then immediately triggered the "uhhuh, there was a bump" thing.
IOW, the code worked correctly as designed. It's not a
"anti-virtualization" feature per se, it's a "detect when virtualization
screws up timing". When virtualization (or SMI etc) does _not_ screw up
timing, it all works fine.
Linus
--
