RE: [Xen-devel] xenoprof passive profiling and "mode" setting

["Santos, Jose Renato G" <joserenato.santos@xxxxxx>]

Ray is right.
We should set the mode correctly in Xen (for both paravirtualized and
HVM guests) and fix Oprofile to use mode instead of relying on PC range.
This would be a good opportunity to fix the way Oprofile determine the
kernel PC range for passive domains. Right now the PC range is defined
by hardcoded constants which obviously is not the right thing to do.

Renato

>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>> Ray Bryant
>> Sent: Thursday, July 06, 2006 9:47 AM
>> To: Yang, Xiaowei
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] xenoprof passive profiling and 
>> "mode" setting
>> 
>> 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)
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel