From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 13:51:58 +0200 Message-ID: <4B87B5DE.30503@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226104437.GB7463@elte.hu> <4B87AF44.9090702@redhat.com> <20100226114217.GI7463@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes Sorensen , Joerg Roedel , KVM General , Peter Zijlstra , Zachary Amsden , Gleb Natapov , ming.m.lin@intel.com, "Zhang, Yanmin" , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , Arjan van de Ven , Fr??d??ric Weisbecker , Arnaldo Carvalho de Melo To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49646 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935392Ab0BZLxH (ORCPT ); Fri, 26 Feb 2010 06:53:07 -0500 In-Reply-To: <20100226114217.GI7463@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 01:42 PM, Ingo Molnar wrote: > * Jes Sorensen wrote: > > >> On 02/26/10 11:44, Ingo Molnar wrote: >> >>> Direct access to counters is not something that is a big issue. [ Given that i >>> sometimes can see KVM redraw the screen of a guest OS real-time i doubt this >>> is the biggest of performance challenges right now ;-) ] >>> >>> By far the biggest instrumentation issue is: >>> >>> - availability >>> - usability >>> - flexibility >>> >>> Exposing the raw hw is a step backwards in many regards. The same way we dont >>> want to expose chipsets to the guest to allow them to do RAS. The same way we >>> dont want to expose most raw PCI devices to guest in general, but have all >>> these virt driver abstractions. >>> >> 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. > Agreed - if both the host and guest want the pmu, the host wins. This is what we do with debug registers - if both the host and guest contend for them, the host wins. >> Emulating the PMU rather than using the real one, makes the numbers far less >> useful. The most useful way to provide PMU support in a guest is to expose >> the real PMU and let the guest OS program it. >> > 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. > A native API to the host will lock out 100% of the install base now, and a large section of any future install base. > 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) > No, stop and restart the counters on every exit/entry, so the guest doesn't observe any host data. >> 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. > > It would be the other way round - the host would steal the pmu from the guest. Later we can try to time-slice and extrapolate, though that's not going to be easy. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.