On 01/06/2011 12:38 PM, Alexander Graf wrote:
<snip>
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.
We do - register kvmclock and check to make sure the version before and
after time computations to be sure the frequency hasn't changed.
This doesn't even require an interrupt.
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.
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.
That doesn't sound to me like they're unaffected?
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.
So how does the guest know that something changed when it's migrated from an AMD machine to an Intel machine?
That can and never should happen. Simply too much state in the guest
depends on CPU type, different workarounds are enabled for things, and
even different instruction sets are activated.
There is no reward for the kind of complexity involved.
Zach
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
