Re: Some Code for Performance Profiling

[Avi Kivity <avi@redhat.com>]

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.