On 08/11/2012 16:45, "Tim Deegan" wrote:
>>> I wonder whether the overflow handling should just be removed, or made
>>> conditional on a command-line parameter, or on the 32-bit platform counter
>>> being at least somewhat likely to overflow before a softirq occurs -- it
>>> seems lots of systems
On 08/11/2012 14:28, "Ian Campbell" wrote:
>>> There appears to be a certain amount of hardware-specificness to the
>>> issue -- so I'm wondering if maybe there are some platforms whose tsc is
>>> not as monotonically increasing as it needs to be...
>>
>> plt_* timestamps are not derived from TS
On 07/11/2012 17:40, "Keir Fraser" wrote:
> On 07/11/2012 13:22, "Ian Campbell" wrote:
>
>>>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
>>>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
>>>&
On 08/11/2012 13:53, "Jan Beulich" wrote:
>>> Is it? My understanding was that plt_stamp64 is just a software
>>> extension to the more narrow HW counter, and hence the low
>>> plt_mask bits would always be expected to be identical.
>>
>> No, plt_stamp is simply the HW counter time at which plt_
On 08/11/2012 11:43, "Ian Campbell" wrote:
>>> I'll leave this to Keir (who wrote the debugging patch) to answer but it
>>> looks to me like it should be useful!
>>
>> I'm scratching my head. plt_wrap is earlier than plt_now, which should be
>> impossible.
>
> impossible due to guarantees made
On 08/11/2012 09:39, "Jan Beulich" wrote:
> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
> plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
> tsc_stamp=e3839fcb0273
(below is the compl
On 07/11/2012 13:22, "Ian Campbell" wrote:
>>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
>>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
>>> plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
>>> tsc_stamp=e3839fcb0273
>>
>> (below is the complete xm dmes
On 23/11/2009 16:44, "Ian Campbell" wrote:
>> But this is not just the return-to-user-space path you're changing, but
>> also the hypercall one. You certainly don't want an iret in that case.
>
> Don't the hypercalls already always go via iret?
> -testw $TRAP_syscall,4(%rsp)
> -j
8 matches
Mail list logo
