[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-ppc-devel
Subject:    =?WINDOWS-1252?Q?Re:_[XenPPC]_Profiling_in_xen_=96_ppc_considera?=
From:       Jimi Xenidis <jimix () watson ! ibm ! com>
Date:       2007-03-22 15:22:15
Message-ID: 6298163F-C69E-4BB0-9571-3A4689B28B1E () watson ! ibm ! com
[Download RAW message or body]


On Mar 19, 2007, at 10:48 AM, Christian Ehrhardt wrote:

> Jimi Xenidis wrote:
>> ...
>> There really very little Linux work to do here.  We need:
>>  1. An hcall that turn the performance monitor on for the domain
>>  2. Save and restore the relevant registers for any domain that is  
>> has it turned on.
>>  3. Turn it off for domains that have it disabled.
>>
>> you can see the hcall being setup here:
>>   arch/powerpc/platforms/pseries/setup.c pSeries_setup_arch 322  
>> ppc_md.enable_pmcs = pseries_lpar_enable_pmcs;
>>
>> ...
>
> I have evaluated all three items you listed above and I think to  
> know now what to do to implement them in detail. I will post a  
> refined version of your list after  I have clarified the last open  
> thing. You suggested to use the hcall to enable performance  
> monitoring and I looked at the definition. The hcall currently  
> contains a lot of information like perf granularity, function  
> pointer, ...

I'm confused, which hcall? the PAPR hcall or the Xen hcall.  I  
suggest the PAPR.

> Currently I expect to need only to set a interdomain valid flag  
> telling xen "there is some profiling in progress"

I do not think this is necessary for the first step of enabling  
active domain oprofiling.

> and optional a per domain flag "this one is currently profiling"

This one _is_ necessary, since you will need to know if save and  
restore are necessary.

> via an hcall for the first step of the implementation. Because the  
> guest can write all performance special purpose registers xen needs  
> only this flag to know if it has to store/recover the perfmon  
> registers.

If the guest did not make the hcall to request performance monitor  
unit (PMU) then we should blindly turn it off, always.
 From a security perspective when we do not restore the PMU we should  
really zero everything as well as turn it off since these registers  
could provide a covert channel.

> We will need to restore MSR0/1,MSRA, PMC also for non-profiling  
> guests in context switch from a profiling one to non profiling  
> guests, because of that the easiest first implementation is  
> something like the following in context_switch().
> ...
> if (perf_mon_in_use) {
>   save/restore  MSR0/1,MSRA,PMC's
> }

This is too course grained, how about:
   if (is_active(prev)) {
       save PMU
   }
   if (is_active(next)) {
       restore PMU
   } else {
       clear PMU
   }
	
> ...
> This will become more sophisticated in future but I currently  
> expect that we will not need the function pointer or profiling  
> granularity there for guest sampling. The only thing I currently  
> expect for the function pointer is to tell xen the place where to  
> report hypervisor samples in one of the next implementation steps.

Is this the function pointer in the Xen hcall, I don't think this is  
usable or necessary for the active model.

> Should/Can I use this complex hcall to set that simple flag e.g. by  
> skipping all other attributes or do we need a new one?

We should use the PAPR call that I sent the spec out for.

-JX



_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[prev in list] [next in list] [prev in thread] [next in thread]