On 02/26/10 14:06, Ingo Molnar wrote:
* Jes Sorensen<Jes.Sorensen@xxxxxxxxxx> wrote:
Well you cannot steal the PMU without collaborating with perf_event.c, but
thats quite feasible. Sharing the PMU between the guest and the host is very
costly and guarantees incorrect results in the host. Unless you completely
emulate the PMU by faking it and then allocating PMU counters one by one at
the host level. However that means trapping a lot of MSR access.
It's not that many MSR accesses.
Well it's more than enough to double the number of MSRs KVM has to track
on switches.
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.
If a PMU can really count stuff on another CPU, then we shouldn't allow
PMU access to any application at all. It's more than just a KVM guest vs
a KVM guest issue then, but also a thread to thread issue.
My idea was obviously not to expose host timings to a guest. Save the
counters when a guest exits, and reload them when it's restarted. Not
just when switching to another task, but also when entering KVM, to
avoid the guest seeing overhead spent within KVM.
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.
As I wrote earlier, at that level we have to do it all emulated. In
this case, providing any of this to a guest seems to be a waste of time
since the interface will cost way too much in trapping back and forth
and you have contention with the very limited resources in the PMU with
just 5 counters to pick from on Core2.
The guest PMU will think it's running on top of real hardware, and
scaling/estimating numbers like the perf_event.c code does today,
except that it will be using already scaled and estimated numbers for
it's calculations. Application users will have little use for this.
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)
Well either you allow access to the PMU or you don't. If you allow
direct access to the PMU counters, but not the control registers, you
have to specify the counter sizes to match that of the host, making it
impossible to really emulate core2 on a non core2 architecture etc.
Jes
--
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
