RE: [Xen-devel] Revisiting the Xenoprof problem

["Santos, Jose Renato G" <joserenato.santos@xxxxxx>]

>
> So the xen passive domain support needs to be accepted into
> oprofile before the matching patches get accepted into Xen?

  That was the original plan. However since no one is working on modifying the 
patches to attend John Levon requests I think this is not going to happen 
anytime soon. So I am suggesting to change the original plan and merge the Xen 
fix to support oprofile 0.9.3. now. We should reserve the cpu buffer escape 
codes for Xen in mainline Oprofile (to avoid the same problem in future 
Oprofile versions) and get the changes to Xen merged.

The main question is how to change Xen to support newer versions of Oprofile 
without breaking instalations using older versions.

Here is a suggestion.
We could create a new xenoprof operation (in xenoprof hypercall) to tell Xen to 
use the new version of the CPU escape codes (used to represent domain 
switches). We would then modify oprofile patches for passive domain support to 
call this hypercall for oprofile versions 0.9.3 and later. By default Xen would 
use the older version of the escape code if the new xenoprof hypercall is not 
invoked, enabling instalations with oprofile 0.9.2 and older to continue 
working, since they will not invoke the new hypercall.

Does this seems reasonable?
Keir, would this be acceptable?
If we reach agreement I can create the Xen and Oprofile patches

Thanks

Renato

> Is there going to be a placeholder or some other entry in
> oprofile cvs, so people know that a define is reserved for
> Xenoprof in  daemon/opd_interface.h?
>
> Any thoughts on how to determine whether the old or new
> xenoprof interface is being used. The oprofile kernel-user
> space interface doesn't have versioning information.
>
> -Will
>

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