Sure, I'm not saying your patch is bad or goes in the wrong direction. I'd just think it'd be awesome to have an easy way for the guest OS to know that something as crucial as TSC reading speed got changed, hopefully even TSC frequency. Having any form of notification leaves open doors for someone to implement something (think proprietary OSs or out-of-service OSs here). Having no notification leaves us with no choice but taking the penalty and keeping the guest less informed than it has to be.
So how does the guest know that something changed when it's migrated from an AMD machine to an Intel machine?On Intel RDTSCP traps along with RDTSC. This means that you can't have a trapping, constant rate TSC for userspace without also paying the overhead for reading the TSC for kvmclock. This is not true on SVM, where RDTSCP is a separate trap, allowing optimization.
Would it make sense to add a kvmclock interrupt to notify the guest of such a change?kvmclock is immune to frequency changes, so it needs no interrupt, it just has a version controlled shared area, which is reset.
That doesn't sound to me like they're unaffected?We indicate to pvclock users that the TSC is being trapped, to allow
avoiding overhead and directly using RDTSCP (only for SVM). This
optimization is not yet implemented.