On 02/26/2010 03:06 PM, Ingo Molnar wrote:
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.
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)
There is nothing secret in the host PMU, and it's easy to clear out the
counters before passing them off to the guest.
That's wrong. On some CPUs the host PMU can be used to say sample aspects of
another CPU, allowing statistical attacks to recover crypto keys. It can be
used to sample memory access patterns of another node.
There's a good reason PMU configuration registers are privileged and there's
good value in only giving a certain sub-set to less privileged entities by
default.
Even if there were no security considerations, if the guest can observe
host data in the pmu, it means the pmu is inaccurate. We should expose
guest data only in the guest pmu. That's not difficult to do, you stop
the pmu on exit and swap the counters on context switches.
Having an allocation scheme and sharing it with the host, is a perfectly
legitimate and very clean way to do it. Once it's given to the guest, the
host knows not to touch it until it's been released again.
'Full PMU' is not the granularity i find acceptable though: please do what i
suggested, event granularity allocation and scheduling.
We are rehashing the whole 'perfmon versus perf events/counters' design
arguments again here really.
Scheduling at event granularity would be a good thing. However we need
to be able to handle the guest using the full pmu.
Note that scheduling is only needed if both the guest and host want the
pmu at the same time - and that should be a rare case and not the one to
optimize for.
You need to integrate it properly so that host PMU functionality still
works fine. (Within hardware constraints)
Well with the hardware currently available, there is no such thing as clean
sharing between the host and the guest. It cannot be done without messing up
the host measurements, which effectively renders measuring at the host side
useless while a guest is allowed access to the PMU.
That's precisely my point: the guest should obviously not get raw access to
the PMU. (except where it might matter to performance, such as RDPMC)
That's doable if all counters are steerable. IIRC some counters are
fixed function, but I'm not certain about that.
--
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
