Tom,
Thanks for the HVM patches.
This is good news
We are now able to profile HVM guests (both SVM and VT)(in passive mode)
using Tom's patches combined with the attached new version of oprofile.
The attached patch (r3) combines the old oprofile patch (r2) with the
patch "oprofile-0.9.1-fix-hvm-addr-overlap.patch" that Tom mentioned and
included in his post.
After Tom's fixes are merged, this is the only patch that will be
needed.
The patch is for oprofile 0.9.1. Oprofile 0.9.2, which will be release
soon, will include XenOprofile support for active domains but it will
not support passive domains. I will generate a patch with passive domain
support for oprofile 0.9.2 when it is released.
I hope Tom patches are accepted and make into Xen 3.0.3
Thanks
Renato
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Woller, Thomas
> Sent: Friday, September 15, 2006 9:19 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] [HVM][XENOPROFILE][RFC][0/3] xenoprofile
> HVM patches
>
> Keir,
> The following 3 patches allow HVM (SVM and VT) guests to be
> passively profiled using the very latest patches from Renato.
> These patches apply to 11470.
> Renato's patches:
> http://xenoprof/sourceforge.net oprofile-0.9.1-xen-r2.patch
> And also a patch not posted FAIK
> (oprofile-0.9.1-fix-hvm-addr-overlap.patch) which is in the attached
> tar.bz2 file.
>
> hvm_xenoprofile_1.patch -
> The first patch is merely the same patch that I posted a few
> weeks ago.
> The STGI code is moved from the exits.S files, and into the
> vmexit handler. The extra do_nmi() is removed allowing the
> host to handle the NMI when the stgi instruction is executed.
> This patch allows the second patch to properly set "guest
> NMI" flag for the oprofile code to determine proper rip/eip and mode.
>
> hvm_xenoprofile_2.patch -
> The second patch adds the actual xenoprofile fixes for SVM:
>
> 1) hvm function (svm_oprofile_get_eip()) This new hvm table
> function is called from the op_module_athlon.c code, and
> returns the proper eip and "mode" for use in the
> xenoprof_log_event() function.
>
> 2) The vmexit handler code now checks the exitcode and if an
> NMI was intercepted, then prior to the stgi(), a flag
> (VGCF_hvm_guest_nmi) is
> set in the v->arch.guest_context.flags field. The VGCF_hvm_guest_nmi
> bit is checked during NMI processing via the hvm function callback.
>
> hvm_xenoprofile_3.patch -
> The third patch adds the actual xenoprofile fixes for VT:
> I checked (verified by Renato), that the VT traces look ok
> also. There is some code that I am unsure about in the
> vmx_oprofile_get_eip(): i.e using the __vmread() to get eip
> might not be in the proper context, and then secondly I am
> not sure how to determine the guest CPL level.
>
> Overall, these patches seem to work fine for 32bit
> hypervisor, as well as 64bit hypervisor with 32bit and 64bit
> HVM guests. You do need to use both of Renato's oprofile
> patches on top of 0.9.1. With another oprofile release soon
> (this week?), I believe that some of the "r2"
> patch will be incorporated into 0.9.2, but not sure which parts.
>
> There certainly might be a better way to obtain the eip/mode,
> but since the SVM code is not calling do_nmi() then the host
> context will handle the NMI, and there must be some mechanism
> to properly setup the eip/mode in the op_model code
> indirectly. I am not sure if the VT code requires the same
> approach since do_nmi() is called directly, and the eip/mode
> could be passed directly to this function.
>
> The attached tar.bz2 file contains some example logs, and
> some scripts from Ray Bryant (AMD) for extracting and
> normalizing each of the profiling buckets. There is a brief
> README for using the scripts.
>
> We'd like to see this get into 3.0.3 if possible. Renato has
> reviewed the patches, but not actually tested these patches
> on his platforms.
> Feedback appreciated,
> Tom Woller
>
>
>
oprofile-0.9.1-xen-r3.patch
Description: oprofile-0.9.1-xen-r3.patch
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home