|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|