On 02/26/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
Or do you mean to define a new, kvm-specific pmu model and feed it off the
host pmu? In this case all the guests will need to be taught about it,
which raises the compatibility problem.
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
May be one too many, for certain guests. Of course it may be argued
that if the guest wants performance monitoring that much, they will upgrade.
Certainly guests that we don't port won't be able to use this. I doubt
we'll be able to make Windows work with this - the only performance tool
I'm familiar with on Windows is Intel's VTune, and that's proprietary.
2) Once a Linux guest has upgraded, it will work in the future, with _any_
future CPU - _without_ having to upgrade the guest!
Dont you see the advantage of that? You can instrument an old system on new
hardware, without having to upgrade that guest for the new CPU support.
That also works for the architectural pmu, of course that's Intel only.
And there you don't need to upgrade the guest even once.
The arch pmu seems nicely done - there's a bit for every counter that
can be enabled and disabled at will, and the number of counters is also
determined from cpuid.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
