|
|
|
|
|
|
|
|
|
|
xen-ppc-devel
Re: [XenPPC] Profiling in xen – ppc considerations
On Mon, 2007-03-19 at 15:48 +0100, 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, ...
There is no function pointer. There is "high"/"low" granularity. I
haven't really looked into this area so I'm not sure what those
correspond to, but at worst we could ignore them for now.
> Currently I expect to need only to set a interdomain valid flag telling
> xen "there is some profiling in progress" and optional a per domain flag
> "this one is currently profiling" 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.
> 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 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.
> 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?
I think you should use the current H_PERFMON hcall. It's really not
complex...
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
|
|