| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Proposal for Xen support of performance monitoring andde
> Rik van Riel pointed me at the Santos's patch for oprofile support.
> There are some differences between the two approaches. The
> Xen oprofile
> support by HP pretty much just supports oprofile and was
> designed to get
> some information about what was going on in the Xen hypervisor. It
> doesn't provide access to the other performance monitoring (or
> debugging) hardware.
The extended xen-oprofile is a useful tool for getting a global view of
what's going on in the whole machine.
I think what you're proposing is for enabling a guest to get a better
idea of what's going on while it is running, which is also useful.
You can't really mix the two modes of operation on the same system, at
least not in the general case.
> > I can certainly see some merit in having fine grained access control
> > over MSRs, though for the case of perf counter registers I wander
> > whether we'd be better off with some higher-level interface?
>
> I was aiming for minimal support low-level, trying to follow the
> existing Xen approach of not coding too much knowledge about
> the system
> in Xen. Make the MSR registers visible and make sure that a guest OS
> cannot clobber other guest OSs. The guests OS decide how to use the
> performance monitoring hw. The hypervisor needs a list of which
> registers are in which class, but the hypervisor doesn't need to know
> the details of what the registers do.
It seems sensible to incorporate a simple mechanism for enabling
fine-grained access control to msr's, and also code to save/restore msr
values that have been changed when context switching between guests.
One issue for guests that are using this mechanism is that I don't
believe it's possible to selectively count events in ring 1 vs ring 0.
Hence it will also count events in Xen during hypercalls and interrupt
handling. In some cases this will be what's wanted, in others, not. I
guess we could slectively save/restore counter values when
entering/leaving Xen, but that's slow and ugly.
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home