On Wed, 2024-03-06 at 09:48 +0000, Paul Durrant wrote:
> 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.
Right. FWIW it looks like that because that's how it is in Xen:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=76e5a428e1e
I do agree that (uint32_t) cast is superfluous. I just don't know
whether I care more about that, or the (cosmetic) difference from how
Xen implements the check.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
