> Balaji Rao wrote: >> On Wednesday 30 January 2008 11:11:51 pm Avi Kivity wrote: >> >>> Markus Armbruster wrote: >>> >>>> System-wide profiling of the *virtual* machine is related to profiling >>>> just a process. That's hard. I guess building on Perfmon2 would make >>>> sense there, but as long as it's out of tree... Can we wait for it? >>>> If not, what then? >>>> >>> Give the guest access to the real PMU. Save them on every exit >>> (switching profiling off), and restore them on every entry (switching >>> profiling on). The only problem with this is that it is very cpu model >>> dependent, losing the hardware independence that virtual machines have. >>> If you are satisfied with the architectural performance counters, then >>> we even have hardware independence. >>> >> But don't the architectural performance counters vary between Intel and AMD >> cpus ? AFAIK, they do. And, this would pose problems during migration >> between >> Intel and AMD hosts. >> >> > > The also vary between Intel hosts of different models, and likely > different AMD hosts as well. The PMU is not architectural (or, in other > words, model specific).
Intel has an architectural PMU now, but it only works on relatively new CPUs and not on AMD. >> I am not sure how important is it to support migration between Intel and AMD >> hosts. If it were not that important, then IMO we could go ahead with >> exposing >> the real PMU. Maybe we could warn users against running profilers in the >> guest >> if they intend it to to be Intel<->AMD migrateable ? >> > > We can give the user the option to expose only the architectural PMU > (which is quite limited) and have cross-model migration, or to expose > the full PMU and lose hardware independence. There is no really an architectural PMU if you consider boxes beyond relatively new Intel CPUs (which got one) But on the other hand in my experience most PMU users use relatively simple few counters (e.g. 90+% likely the local variant of CPU_CYCLES_NONHALTED) so it would be in theory possible to translate those by traps from a different CPU's format in the monitor into the local MSR. The only trouble is that is no architectural way to tell the guest "i support only counter X Y Z" and also no nice way to reject a particular counter except for just not ticking. And trapping these MSR writes might be too slow for some applications. Still I suspect just emulating cycles non halting would be a decent 95+% solution. -Andi ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
