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.
-boris
>>> 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
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. Can you tell me more about the oprofile/perf background? 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
----- 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 -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
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#L660After 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
Thanks for explanations. :) I was trying to find out what''s the difference between AMD and Intel, but had not had time to do so. From your write up, I get clearer understanding. Shan Haitao -----Original Message----- From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com] Sent: Tuesday, April 02, 2013 4:53 AM To: Shan, Haitao Cc: JBeulich@suse.com; xen-devel@lists.xen.org Subject: Re: [Xen-devel] LVTPC masking in Intel VPMU code 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#L660After 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