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. This pmu-emulation will still use the perf-infrastructure for scheduling the pmu registers, programming the pmu registers and things like that. This could be used for example to emulate 48bit counters for the guest even if the host only supports 32 bit counters. We even need the perf infrastructure when we need to reinject pmu events into the guest. > - It's more secure: the host can have a finegrained policy about what kinds of > events it exposes to the guest. It might chose to only expose software > events for example. What do you mean by software events? 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
