On Mon, Mar 01, 2010 at 09:44:50AM +0100, Ingo Molnar wrote: > There's a world of a difference between "will not use in certain usecases" and > "cannot use at all because we've designed it so". By doing the latter we > guarantee that sane shared usage of the PMU will never occur - which is bad. I think we can emulate a real hardware pmu for guests using the perf infrastructure. The emulation will not be complete but powerful enough for most usecases. Some steps towards this might be: 1. Enhance perf to count pmu events only when cpu is in guest mode. 2. For every emulated performance counter the guest activates kvm allocates a perf_event and configures it for the guest (we may allow kvm to specify the counter index, the guest would be able to use rdpmc unintercepted then). Event filtering is also done in this step. 3. Before vmrun the guest activates all its counters, this can fail if the host uses them or the requested pmc index is not available for some reason. 4. Some additional magic to reinject pmu events into the guest > Think about it: this whole Linux thing is about 'sharing' resources. That > concet really works and permeates everything we do in the kernel. Yes, it's > somewhat hard for the PMU but we've done it on the host side via perf events > and we really dont want to look back ... As I learnt at the university this whole operating system thing is about managing resource sharing and hardware abstraction ;-) > My experience is that once the right profiling/tracing tools are there, people > will use them in every which way. The bigger a box is, the more likely shared > usage will occur - just statistically. Which coincides with KVM's "the bigger > the box, the better for virtualization" general mantra. With the above approach the only point of conflict occurs when the host wants to monitor the qemu-processes executing the vcpus which want to do performance monitoring of their own or cpu-wide counting. Joerg -- 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
