On 02/26/2010 01:42 PM, Ingo Molnar wrote:
* Jes Sorensen<Jes.Sorensen@xxxxxxxxxx> wrote:
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of performance challenges right now ;-) ]
By far the biggest instrumentation issue is:
- availability
- usability
- flexibility
Exposing the raw hw is a step backwards in many regards. The same way we dont
want to expose chipsets to the guest to allow them to do RAS. The same way we
dont want to expose most raw PCI devices to guest in general, but have all
these virt driver abstractions.
I have to say I disagree on that. When you run perfmon on a system, it is
normally to measure a specific application. You want to see accurate numbers
for cache misses, mul instructions or whatever else is selected.
You can still get those. You can even enable RDPMC access and avoid VM exits.
What you _cannot_ do is to 'steal' the PMU and just give it to the guest.
Agreed - if both the host and guest want the pmu, the host wins. This
is what we do with debug registers - if both the host and guest contend
for them, the host wins.
Emulating the PMU rather than using the real one, makes the numbers far less
useful. The most useful way to provide PMU support in a guest is to expose
the real PMU and let the guest OS program it.
Firstly, an emulated PMU was only the second-tier option i suggested. By far
the best approach is native API to the host regarding performance events and
good guest side integration.
A native API to the host will lock out 100% of the install base now, and
a large section of any future install base.
Secondly, the PMU cannot be 'given' to the guest in the general case. Those
are privileged registers. They can expose sensitive host execution details,
etc. etc. So if you emulate a PMU you have to exit out of most PMU accesses
anyway for a secure solution. (RDPMC can still be supported, but in close
cooperation with the host)
No, stop and restart the counters on every exit/entry, so the guest
doesn't observe any host data.
We can do this in a reasonable way today, if we allow to take the PMU away
from the host, and only let guests access it when it's in use. [...]
You get my sure-fire NAK for that kind of crap though. Interfering with the
host PMU and stealing it, is not a technical approach that has acceptable
quality.
It would be the other way round - the host would steal the pmu from the
guest. Later we can try to time-slice and extrapolate, though that's
not going to be easy.
--
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
