Re: ITIMER_VIRTUAL implementation seems wrong?

On 9/18/25 10:23, Kyle Evans wrote:
> Hi,
> 
> Paul Floyd has been trying to diagnose a hang they see in the valgrind
> test suite under VirutalBox.  The test[0] is fairly simple and uses the
> process virtual timer; just running it outside of Valgrind, you'll maybe
> note that the runtime varies pretty wildly from real hardware to virtualized
> environments.
> 
> I've only done a ~10 minute review on the virtual timer implementation,
> but it doesn't seem quite right?  AFAICT, we only decrement from the
> virtual timer if we managed to catch a hardclock while still executing
> in usermode.
> 
> That seems like it would leave us open to shenanigans like this, because
> they're effectively racing syscalls against timer interrupts and getting
> quite unlucky, accumulating a pretty large error in the process.   This
> probably isn't how the virtual timer is supposed to work, right?  It seems
> like time from syscall <-> syscall and interrupt <-> syscall should still
> be measured all the same.
> 
> Thanks,
> 
> Kyle Evans
> 
> [0] https://sourceware.org/git/?p=valgrind.git;a=blob_plain;f=none/tests/freebsd/bug452274.c;hb=HEAD
> 

Hi,

I think my assessment here is wrong and the distinction maybe does not
matter; in this bhyve vm, for instance, I'm running with a clock at
~10msec resolution that we'll adjust their timer up to that.  That alone
is sufficient to blow up the runtime significantly.

Thanks,

Kyle Evans