On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote:
>
> On 12/06/2020 12:26, Volodymyr Babchuk wrote:
> > Hi Jurgen,
> >
> > thanks for the review
> >
> > On Fri, 2020-06-12 at 06:36 +0200, Jürgen Groß wrote:
> >
> > > On 12.06.20 02:22, Volodymyr Babchuk wrote:
> >
> > [...]
> >
> > > > +void vcpu_end_irq_handler(void)
> > > > +{
> > > > + int delta;
> > > > +
> > > > + if (is_idle_vcpu(current))
> > > > + return;
> > > > +
> > > > + ASSERT(current->irq_nesting);
> > > > +
> > > > + if ( --current->irq_nesting )
> > > > + return;
> > > > +
> > > > + /* We assume that irq handling time will not overflow int */
> > >
> > > This assumption might not hold for long running VMs.
> >
> > Basically, this value holds time span between calls to schedule(). This
> > variable gets zeroed out every time scheduler requests for time
> > adjustment value. So, it should not depend on total VM run time.
> This is assuming that the scheduler will be called. With the NULL
> scheduler in place, there is a fair chance this may never be called.
>
> So I think using a 64-bit value is likely safer.
Well, I wanted to use 64-bit value in the first place. But I got the
impression that atomic_t supports only 32-bit values. At least, this is
what I'm seeing in atomic.h
Am I wrong?
> Cheers,
>
