[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Revisiting the Xenoprof problem
> > 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |