Re: [PATCH v1 00/13] x86/PMU: Xen PMU PV support

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 09/11/2013 01:01 PM, George Dunlap wrote:
> On 10/09/13 16:47, Boris Ostrovsky wrote:
>> On 09/10/2013 11:34 AM, Jan Beulich wrote:
>>>>>> On 10.09.13 at 17:20, Boris Ostrovsky 
>>>>>> <boris.ostrovsky@oracle.com> wrote:
>>>> This version has following limitations:
>>>> * For accurate profiling of dom0/Xen dom0 VCPUs should be pinned.
>>>> * Hypervisor code is only profiled on processors that have running 
>>>> dom0 VCPUs
>>>> on them.
>>> With that I assume this is an RFC rather than full-fledged submission?
>>
>> I was thinking that this would be something like stage 1 
>> implementation (and
>> probably should have mentioned this in the cover letter).
>>
>> For this stage I wanted to confine all changes on Linux side to xen 
>> subtrees.
>> Properly addressing the above limitation would likely require changes 
>> in non-xen
>> sources (change in perf file format, remote MSR access etc.).
>
> I think having the vpmu stuff for PV guests is a great idea, and from 
> a quick skim through I don't have any problems with the general 
> approach.  (Obviously some more detailed review will be needed.)
>
> However, I'm not a fan of this method of collecting perf stuff for Xen 
> and other VMs together in the cpu buffers for dom0.  I think it's 
> ugly, fragile, and non-scalable, and I would prefer to see if we could 
> implement the same feature (allowing perf to analyze Xen and other 
> vcpus) some other way.  And I would rather not use it as a "stage 1", 
> for fear that it would become entrenched.

I can see how collecting samples for other domains may be questionable 
now (DOM0_PRIV mode) since at this stage there is no way to distinguish 
between samples for non-priviledged domains.

But why do you think that getting data for both dom0 and Xen is 
problematic? Someone has to process Xen's samples and who would do this 
if not dom0? We could store samples in separate files (e.g. 
perf.data.dom0 and perf.data.xen) but that's toolstack's job.

>
> I think at the hackathon we discussed the idea of having "fake" cpus 
> -- each of which would correspond to either a pcpu with Xen, or a vcpu 
> of another domain.  How problematic is that approach?

This is what I was planning to do later.  Those would be "fake" CPUs in 
the sense that their cpuids would be something like (vcpuID | domainID) 
or (PCPU|<sometag>). But it would be a natural extension of what is 
being done now.

> For phase 1 can we just do vpmu for PV guests (and add hooks to allow 
> domains to profile themselves), and look into how to profile Xen and 
> other VMs as a stage 2?


-boris