Re: [Xen-devel] LVTPC masking in Intel VPMU code

["Shan, Haitao" <haitao.shan@xxxxxxxxx>]

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@xxxxxxxxxx] 
Sent: Tuesday, April 02, 2013 4:53 AM
To: Shan, Haitao
Cc: JBeulich@xxxxxxxx; xen-devel@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] LVTPC masking in Intel VPMU code

On 03/29/2013 08:39 AM, Boris Ostrovsky wrote:
> ----- haitao.shan@xxxxxxxxx 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@xxxxxxxx]
>> 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@xxxxxxxxxx>
>> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel