On 02/26/2010 03:37 AM, Jes Sorensen wrote:
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
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 would only work if you are guaranteed to be able to emulate old
hardware on new hardware. Not going to be feasible, so then we are in a
real mess.
With the 'steal the PMU' messy approach the guest OS has to be
upgraded to the
new CPU type all the time. Ad infinitum.
The way the Perfmon architecture is specified by Intel, that is what we
are stuck with. It's not going to be possible via software emulation to
count cache misses, unless you run it in a micro architecture emulator.
Sure you can count cache misses.
Step 1. Declare KVM to possess a virtual cache hereto unseen to guest VCPUs.
Step 2. Use micro architecture rules to add to cache misses in an
undefined micro-architecture specific way
Step 3. <censored>
Step 4. PROFIT!
The point being, there are no rules required to follow for
architecturally unspecified events. Instructions issued is well defined
architecturally, one of very few such counters, while things like cache
strides and organization are deliberately left to the implementation.
So returning zero is a perfectly valid choice for emulating cache misses.
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
