All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: haitao.shan@intel.com
Cc: JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: LVTPC masking in Intel VPMU code
Date: Mon, 01 Apr 2013 16:53:25 -0400	[thread overview]
Message-ID: <5159F3C5.8030402@oracle.com> (raw)
In-Reply-To: <354e1583-20e2-498b-a816-c38429867c0b@default>

On 03/29/2013 08:39 AM, Boris Ostrovsky wrote:
> ----- haitao.shan@intel.com wrote:
>
>> Hi, Jan,
>>
>> This is a pretty old code. :) I did not copy or borrow the oprofile
>> and perf code at all. Thus, I am not aware of the quirk. (Actually, I
>> don't know what quirk you mean).
>> For Xen's PMI handler, I just unmask the source and deliver a virtual
>> one. Here in this code, I see I unmasked the physical one and mask the
>> virtual LVTPC.
> The reason I am asking is because I am trying to factor out common code
> from VMX and SVM into VPMU code. AMD code doesn't have this and I can run
> on Intel (at least on the HW that I have) without these two lines as well.
>
> But more importantly I am not sure I understand why this is needed.
>
>> Can you tell me more about the oprofile/perf background?
> http://lxr.linux.no/#linux+v3.8.5/arch/x86/oprofile/op_model_ppro.c#L143
> and
> http://lxr.linux.no/#linux+v3.8.5/arch/x86/oprofile/op_model_p4.c#L660

After poking around in the SDM I can now see the reason for unmasking
physical APIC --- apparently performance counter interrupt sets the mask
bit in appropriate LVT entry. This is different from AMD behavior, where the
mask bit is not updated.

vlapic update is not technically necessary, except for faithful emulation of
Intel HW.

Seems to me that comments in Linux code (and similar comments in Xen
code)  are somewhat misleading --- this is not a HW quirk but rather the
architectural behavior.

(My earlier assertion that these two lines were not necessary on Intel 
wasn't
correct: I was testing with perf and perf re-arms the counter by writing
control MSR, which triggers LVT update in core2_vpmu_do_wrmsr(). Oprofile
doesn't appear to re-arm and without unmasking the entry it doesn't work
on Intel)

-boris

>
> -boris
>
>
>> Shan Haitao
>>
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Thursday, March 28, 2013 7:26 PM
>> To: Shan, Haitao
>> Cc: xen-devel; Boris Ostrovsky
>> Subject: Re: [Xen-devel] LVTPC masking in Intel VPMU code
>>
>>>>> On 27.03.13 at 22:34, Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> wrote:
>>> Can someone explain why we have these lines in
>>> vpmu_core2.c:core2_vpmu_do_interrupt():
>>>       apic_write_around(APIC_LVTPC, apic_read(APIC_LVTPC) &
>>> ~APIC_LVT_MASKED);
>>>       ...
>>>       vlapic_set_reg(vlapic, APIC_LVTPC, vlapic_lvtpc |
>> APIC_LVT_MASKED);
>>> There is similar code in Linux oprofile with a comment that this is
>> done
>>> due to some sort of
>>> a quirk on P4 and PentiumM. Is this why it's in
>>> core2_vpmu_do_interrupt() as well?
>>>
>>> I don't see a quirk like this in Linux perf code.
>> Haitao, you contributed that code a long while back. Any comment?
>>
>> Jan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2013-04-01 20:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-29 12:39 LVTPC masking in Intel VPMU code Boris Ostrovsky
2013-04-01 20:53 ` Boris Ostrovsky [this message]
2013-04-02  1:29   ` Shan, Haitao
  -- strict thread matches above, loose matches on Subject: below --
2013-03-27 21:34 Boris Ostrovsky
2013-03-28 11:26 ` Jan Beulich
2013-03-29  9:12   ` Shan, Haitao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5159F3C5.8030402@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=haitao.shan@intel.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.