Anthony Liguori wrote: > introduces a subtle semantic change. Previously, timers always ran > before bottom halves whereas after this change, timers may run after > some bottoms halves but before others. While this should be okay in > principle, in practice, I'm sure it'll introduce regressions. I'd be > very surprised if cris wasn't affected by this.
In principle, if it does affect something, it seems likely there is already a buggy race condition. After all, if the timer and bottom half could trigger at the same time, which is the condition where the order is significant, then in principle the timer could have triggered slightly later because it depends on the host alarm behaviour. > But more importantly, I think timer dispatch needs to be part of the > select loop. malc has a git tree that replaces host alarm timers with > select() timeouts. This has a lot of really nice properties like it > eliminates the need for signals and EINTR handling. A move like this > would likely make this more difficult. I agree that select loop is better, but don't you still need a host alarm signal for when the guest is running for a long time without trapping? -- Jamie
