[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.