* Joerg Roedel <joro@xxxxxxxxxx> wrote:
> > - It's 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, it's 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 http://vger.kernel.org/majordomo-info.html
