Re: xenoprof passive profiling and "mode" setting

["Ray Bryant" <raybry@mpdtxmail.amd.com>]

On Wednesday 05 July 2006 21:53, Yang, Xiaowei wrote:
> >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

Xiaowei,

Hmmm.... It seems to me that the pc range thing is at the very least obscure 
(I certainly didn't spot it, but then I've avoided looking at the oprofile 
code).   I'd rather have the mode set correctly for hvm guests (passive 
profiling) as well, and fix the logic downstream in oprofile to deal with it 
correctly without the pc range info.

Besides, isn't this problem in the guest_kernel_mode(regs) macro just going to 
bite someone else later on?   It would make most sense to fix this so it 
works for all guests, not just paravirtualized ones.

-- 
Ray Bryant
AMD Performance Labs                   Austin, Tx
512-602-0038 (o)                 512-507-7807 (c)