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.


Xen-ppc-devel mailing list

Reply via email to