On Wed, 2008-10-01 at 14:34 -0700, Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Alok Kataria wrote:And arguably, storing TSC frequency in CPUID is a terrible interface
I guess, but the bulk of the uses of this stuff are going to be
hypervisor-specific. You're hard-pressed to come up with any other
generic uses beyond tsc.
because the TSC frequency can change any time a guest is entered. It
really should be a shared memory area so that a guest doesn't have to
vmexit to read it (like it is with the Xen/KVM paravirt clock).
It's not terrible, it's actually brilliant.
TSC is part of the
processor architecture, the processor should a way to tell us what speed
it is.
And now we're trying to fiddle around with software wizardry what should
be done in hardware in the first place. Once again, para-virtualization
is basically useless. We can't agree on a solution without
over-designing some complex system with interface signatures and
multi-vendor cooperation and nonsense. Solve the non-virtualized
problem and the virtualized problem goes away.
Jun, you work at Intel. Can you ask for a new architecturally defined
MSR that returns the TSC frequency? Not a virtualization specific MSR.
A real MSR that would exist on physical processors. The TSC started as
an MSR anyway. There should be another MSR that tells the frequency.
If it's hard to do in hardware, it can be a write-once MSR that gets
initialized by the BIOS.
I realize it's the wrong thing for us now, but long term, it's the only
architecturally 'correct' approach. You can even extend it to have
visible TSC frequency changes clocked via performance counter events
(and then get interrupts on those events if you so wish), solving the
dynamic problem too.
Paravirtualization is a symptom of an architectural problem. We should
always be trying to fix the architecture first.
Zach