* Joerg Roedel <joro@xxxxxxxxxx> wrote: > On Fri, Feb 26, 2010 at 02:44:00PM +0100, Ingo Molnar wrote: > > - A paravirt event driver is more compatible and more transparent in the long > > run: it allows hardware upgrade and upgraded PMU functionality (for Linux) > > without having to upgrade the guest OS. Via that a guest OS could even be > > live-migrated to a different PMU, without noticing anything about it. > > > > In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS > > always assumes the guest OS is upgraded to the host. Also, 'raw' PMU state > > cannot be live-migrated. (save/restore doesnt help) > > I agree with your arguments, having this soft-pmu for the guest has some > advantages over raw pmu access. It has a lot of advantages if the guest > migrated between hosts with different hardware. > > But I still think we should have both, a soft-pmu and a pmu-emulation (which > is a more accurate term than 'raw guest pmu access') that looks to the guest > as a real hardware pmu would look like. On a linux host that is dedicated > to executing virtual kvm machines there is little point in sharing the pmu > between guest and host because the host will probably never use it. 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. Really, similar arguments have been made in the past about different domains of system usage: "one profiling session per system is more than enough, who needs transparent, per user profilers", etc. Such restrictions have been broken through again and again. 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 ... 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. 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
