Jan Kiszka wrote:
> Anthony Liguori wrote:
>> Jan Kiszka wrote:
>>> Anthony Liguori wrote:
>>>  
>>>> If anyone notices a slow down, I'd check this revision.  There may be
>>>> broken bits of code out there that depends on wake up rate.  I've done a
>>>> fair bit of testing and haven't found any but you never know.
>>>>     
>>> OK, here is one brokenness for you: Musicpal (qemu-arm-system) becomes
>>> unusable, sounds is stopping for seconds, even keyboard input is
>>> inpossible, including switching to the monitor console. What should I
>>> check for? Note that this board uses a ptimer to a PIT to the guest. May
>>> this make a difference here?
>>>   

I think I understood the problem:

[...]
timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xca8d90)                  = 0
select(24, [0 5 6 8 23], [], [], {0, 0}) = 0 (Timeout)
ioctl(20, 0x4122, 0xbb)                 = 0
ioctl(20, 0x4122, 0x54)                 = 0
ioctl(20, 0x4122, 0x3)                  = 0
ioctl(20, 0x4122, 0)                    = 0
ioctl(20, 0x4122, 0xac)                 = 0
ioctl(20, 0x4122, 0)                    = 0
ioctl(20, 0x4122, 0x400)                = 0
ioctl(21, USBDEVFS_IOCTL, 0xd64080)     = 0
ioctl(20, 0x4122, 0xc000000000020400)   = 0
semop(34242562, 0x7fff65de5960, 2)      = 0
semop(34242562, 0x7fff65de5970, 1)      = 0
read(19, "\1\0\0\0\0\201\377\377\321Z\2\0\0\0\0\0\'PO&\0\0\0\0\1\0\0\0\377\377\377\377", 128) = 32
timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xca8d90)                  = 1
select(24, [0 5 6 8 23], [], [], {5, 0}^C <unfinished ...>


There is a race between the alarm_timer firing SIGALRM and
main_loop_wait reaching the safe harbor of select (with that infamous 5
second timeout). If the signal comes when already blocked in select, it
will properly resume the latter immediately. But if the timer fired
BEFORE that point, host_alarm_handler will only set a flag that the host
timer has fired, the actual rearming will be done AFTER return from
select. Ooops....

So, select should actually include the host timer as event. timerfd?
Unfortunately a recent Linux-only feature :-/. I don't think we can
rearm the timer from within the signal handler, at least not without
running all the pending qemu timers. And that is surely not a signal
handler job (qemu timer handler aren't thread-safe in general).

Anyone any ideas? /me is thinking a bit more about it as well.

Jan