From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Some Code for Performance Profiling Date: Wed, 07 Apr 2010 22:30:02 +0300 Message-ID: <4BBCDD3A.1050003@redhat.com> References: <6d8082041003310953p33e30819vbb7c2a122bd6becd@mail.gmail.com> <4BB9A08C.4010408@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Nipun sehrawat To: Jiaqing Du Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7224 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743Ab0DGTaJ (ORCPT ); Wed, 7 Apr 2010 15:30:09 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 04/07/2010 10:23 PM, Jiaqing Du wrote: > >> Can your implementation support both simultaneously? >> > What do you mean "simultaneously"? With my implementation, you either > do guest-wide profiling or system-wide profiling. They are achieved > through different patches. Actually, the result of guest-wide > profiling is a subset of system-wide profiling. > > A guest admin monitors the performance of their guest via a vpmu. Meanwhile the host admin monitors the performance of the host (including all guests) using the host pmu. Given that the host pmu and the vpmu may select different counters, it is difficult to support both simultaneously. >>> For guest-wide profiling, there are two possible places to save and >>> restore the related MSRs. One is where the CPU switches between guest >>> mode and host mode. We call this *CPU-switch*. Profiling with this >>> enabled reflects how the guest behaves on the physical CPU, plus other >>> virtualized, not emulated, devices. The other place is where the CPU >>> switches between the KVM context and others. Here KVM context means >>> the CPU is executing guest code or KVM code, both kernel space and >>> user space. We call this *domain-switch*. Profiling with this enabled >>> discloses how the guest behaves on both the physical CPU and KVM. >>> (Some emulated operations are really expensive in a virtualized >>> environment.) >>> >>> >> Which method do you use? Or do you support both? >> > I post two patches in my previous email. One is for CPU-switch, and > the other is for domain-switch. > > I see. I'm not sure I know which one is better! >> Note disclosing host pmu data to the guest is sometimes a security issue. >> >> > For instance? > The standard example is hyperthreading where the memory bus unit is shared among two logical processors. A guest sampling a vcpu on one thread can gain information about what is happening on the other - the number of bus transactions the other thread has issued. This can be used to establish a communication channel between two guests that shouldn't be communicating, or to eavesdrop on another guest. A similar problem happens with multicores. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.