| title: | Re KVM PMU virtualization |
|
* Joerg Roedel <joro@xxxxxxxxxx wrote:
- Its more secure: the host can have a finegrained policy about what kinds of
events it exposes to the guest. It might chose to only expose software
events for example.
What do you mean by software events?
Things like:
aldebaran:~ perf stat -a sleep 1
Performance counter stats for sleep 1:
15995.719133 task-clock-msecs # 15.981 CPUs
5787 context-switches # 0.000 M/sec
210 CPU-migrations # 0.000 M/sec
193909 page-faults # 0.012 M/sec
28704833507 cycles # 1794.532 M/sec (scaled from 78.69%)
14387445668 instructions # 0.501 IPC (scaled from 90.71%)
736644616 branches # 46.053 M/sec (scaled from 90.52%)
695884659 branch-misses # 94.467 % (scaled from 90.70%)
727070678 cache-references # 45.454 M/sec (scaled from 88.11%)
1305560420 cache-misses # 81.619 M/sec (scaled from 52.00%)
1.000942399 seconds time elapsed
These lines:
15995.719133 task-clock-msecs # 15.981 CPUs
5787 context-switches # 0.000 M/sec
210 CPU-migrations # 0.000 M/sec
193909 page-faults # 0.012 M/sec
Are software events of the host - a subset of which could be transparently
exposed to the guest. Same for tracepoints, probes, etc. Those are not exposed
by the hardware PMU. So by doing a soft PMU (or even better: a paravirt
channel to perf events) we gain a lot more than just raw PMU functionality.
performance events are about a lot more than just the PMU, its a coherent
system health / system events / structured logging framework.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at rel="nofollow" vger.kernel.org/majordomo-info.html vger.kernel.org/majordomo-info.html
|
