| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [XenPPC] Profiling in xen – ppc considerations
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
| |
|
Home