RE: ...\n

["Durrant, Paul" <pdurrant@amazon.co.uk>]

> -----Original Message-----
[snip]
> >>
> >> I'll bite... What's ludicrous about wanting to run a guest at a lower
> >> CPU freq to minimize observable change in whatever workload it is
> >> running?
> >
> > *why* would you want to do that? Everybody wants their stuff done
> > faster.
> >
> 
> FWIW, I can see a valid use-case: imagine you're running some software
> which calibrates itself in the beginning to run at some desired real
> time speed but then the VM running it has to be migrated to a host with
> faster (newer) CPUs. I don't have a real world examples out of top of my
> head but I remember some old DOS era games were impossible to play on
> newer CPUs because everything was happenning too fast. Maybe that's the
> case :-)
> 

That is exactly the case. This is not 'some hare-brained money scheme'; there is genuine concern that moving a VM from old h/w to new h/w may cause it to run 'too fast', breaking any such calibration done by the guest OS/application. I also don't have any real-world examples, but bugs may well be reported and having a lever to address them is IMO a good idea.
However, I also agree with Paolo that KVM doesn't really need to be doing this when the VMM could do the job using cpufreq, so we'll pursue that option instead. (FWIW the reason for involving KVM was to do the freq adjustment right before entering the guest and then remove the cap right after VMEXIT).

  Paul