On 05/03/2024 21:12, Sean Christopherson wrote:
On Tue, Mar 05, 2024, Paul Durrant wrote:
On 04/03/2024 23:44, Sean Christopherson wrote:
On Tue, Feb 27, 2024, David Woodhouse wrote:
/*
* Xen has a 'Linux workaround' in do_set_timer_op() which checks for
* negative absolute timeout values (caused by integer overflow), and
* for values about 13 days in the future (2^50ns) which would be
* caused by jiffies overflow. For those cases, Xen sets the timeout
* 100ms in the future (not *too* soon, since if a guest really did
* set a long timeout on purpose we don't want to keep churning CPU
* time by waking it up). Emulate Xen's workaround when starting the
* timer in response to __HYPERVISOR_set_timer_op.
*/
if (linux_wa &&
unlikely((int64_t)guest_abs < 0 ||
(delta > 0 && (uint32_t) (delta >> 50) != 0))) {
Now that I look at it again, since the last test is simply a '!= 0', I don't
really see why the case is necessary. Perhaps lose that too. Otherwise LGTM.
Hmm, I think I'll keep it as-is purely so that the diff shows that it's a just
code movement. There's already enough going on in in this patch, and practically
speaking I doubt anything other than checkpatch will ever care about the "!= 0".
Thanks!
... and now I see I typo-ed 'cast' to 'case'... it was more that
'(uint32_t)' than the superfluous '!= 0' that caught my eye but yes, I
agree, it's code movement so separate cleanup is probably better.
