* Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> wrote: > On 02/26/10 12:42, Ingo Molnar wrote: > > > >* Jes Sorensen<Jes.Sorensen@xxxxxxxxxx> wrote: > >> > >> 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. > > 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. > >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. > >>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. > > 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. > > 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) 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
