Re: [Qemu-devel] Re: LSI: avoid infinite loops

[Paul Brook]

> > > > > > > The Windows driver has SCRIPTS code which busy loops on main
> > > > > > > memory. So give the CPU's a chance to run if that happens.
> > > > > >
> > > > > > I'm kinda surprised this works.  What causes the scripts engine
> > > > > > to be restarted?
> > > > >
> > > > > LSI_ISTAT0_SIGP.
> > > >
> > > > In that case my surprise continues, and this is looking like an
> > > > unbelievably horrid hack.
> > > >
> > > > By my reading you're making LSI_ISTAT0_SIGP effect whatever
> > > > instruction happens to be executing when we stall. You get doubly
> > > > lucky because (a) the guest OS decides to bang on SIGP, even though
> > > > it doesn't need to. And (b) the last instruction executed happens to
> > > > have set dnad to a value that "works". I'm guessing you always happen
> > > > to stop execution on the conditional jump instruction and taking that
> > > > jump doesn't cause any bad effects, right?
> > >
> > > Oh, I'd also be worried what happens if an async IO operation completes
> > > at this point. lsi_command_complete is liable to trample all over your
> > > state.
> >
> > So what do you suggest as a proper fix?
>
> What do you suggest as a proper fix to this problem?

At minimum you need to address the issues I've raised with your current patch.  
Stalling execution temporarily every few hundred instructions and waiting for 
SIGP (or some other trigger) before resuming may be acceptable.  Aborting 
execution and relying on very specific guest OS behavior to give correct 
results is not.  The current code is written with the assumption that 
execution will only stop at very specific points. Your patch breaks this 
assumption.

Ideally you'd also do proper loop detection rather than setting an arbitrary 
limit. I wouldn't be surprised if a good OS can create very long queues.

Paul