Xen devel - Apr 2005 - RE: 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Pratt wrote:
>>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.
Right, mixing the different modes at the same time is not going to work, 
but it would be nice to make the mechanism flexible enough so that the 
same mechanism can be both for local and system-wide profiling.
>>>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.
Yes, the selectivity is ring != 0 or ring ==0. There isn''t the finer 
grain to separate the guest OS from the normal user space.

A place that things might get odd if the domain-0 handles things on the 
behalf of guest domain. The sampling in local mode would not cross 
domains. Thus, a user guest domain might not know that it is having a 
lot of overhead in domain-0. However, in these cases people are probably 
better off doing system-wide sampling.

-Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel