Re: Proposal for Xen support of performance monitoring anddebug hardware

[William Cohen <wcohen@redhat.com>]

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