[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Fwd: RE: [Xen-devel] xenoprof passive profiling and "mode" setting
See below... ---------- Forwarded Message ---------- Subject: RE: [Xen-devel] xenoprof passive profiling and "mode" setting Date: Wednesday 05 July 2006 21:53 From: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx> To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Ray Bryant" <raybry@xxxxxxxxxxxxxxxxx> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx >guest_kernel_mode() does not work for HVM guests. It may need to be >fixed -- it had previously only been used in paravirtual-only contexts. > >It might make sense to invert[*] the predicate and rename to >user_mode(). Then definition is simply ring_3(regs) for x86/32 and >(ring_3(regs) && !((v)->arch.flags & TF_kernel_mode)) for x86/64. > >So maybe: > int mode = 2; > if (guest_mode(regs)) > mode = user_mode(current, regs) ? 0 : 1; Yes, this is a better solution for sure, to take both para-domain and hvm into account. But it's not a problem for now:) _mode_ logic only applies to active domiain. Oprofile doesn't use it for samples between PASSIVE_START_CODE and PASSIVE_STOP_CODE. Rather it relies on PC range to distinguish xen/kernel/app samples. Thanks, Xiaowei ------------------------------------------------------- -- Ray Bryant AMD Performance Labs Austin, Tx 512-602-0038 (o) 512-507-7807 (c) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |