WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Proposal for Xen support of performance monitoring andde

To: "William Cohen" <wcohen@xxxxxxxxxx>
Subject: RE: [Xen-devel] Proposal for Xen support of performance monitoring anddebug hardware
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 22 Apr 2005 22:27:33 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 22 Apr 2005 21:27:38 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVHfqbdWAUBbzRnTuSxcNw/FHA6PQAAFhtw
Thread-topic: [Xen-devel] Proposal for Xen support of performance monitoring anddebug hardware
> 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