Re: [RFC PATCH v3 11/11] tests: add plugin asserting correctness of discon event's to_pc

[Richard Henderson]

On 12/6/24 13:02, Pierrick Bouvier wrote:
> On 12/6/24 00:42, Julian Ganz wrote:
> > Hi Pierrick,
> >
> > December 5, 2024 at 11:28 PM, "Pierrick Bouvier" wrote:
> > > On 12/5/24 13:22, Julian Ganz wrote:
> > > >   December 5, 2024 at 6:30 PM, "Pierrick Bouvier" wrote:
> > > > > We can store the next_expected pc for each instruction (from current_instruction + 
> > > > > insn_length), and we should be able to compare that with the expected from_pc.
> > > > >   This is mostly what contrib/plugins/cflow.c does.
> > > > >
> > > > >   With that, we can test from_pc.
> > > >   I'm not confident that this will work reliably for branch, jump and
> > > >   other "interesting" instructions. But I can have a closer look at the
> > > >   cflow plugin and try to figure out how that plugin handles those cases.
> > > It won't work for latest instructions in a tb (because we don't know what will be the 
> > > next one), but should be good for all the others cases.
> >
> > IIUC qemu will schedule interrupts "opportunistically" between tb
> > executions. If that's the case we'll observe interrupts exclusively
> > after the last instruction in a tb. That strikes me as a serious
> > limitation.
>
> To reuse fancy vocabulary, maybe we should have a distinction between inferable 
> interruptions (interrupt instruction) and uninferable interrupts, triggered by an external 
> event.
>
> In the latter, it *might* be acceptable to not provide a from_pc (let's say a value 0), 
> because there is no useful information in itself, except creating random edges in the 
> control flow graph, which we don't want to do.
>
> What do you think of it?

I think you both are over-complicating things.

Always, env->pc (or whatever) within cc->cpu_exec_interrupt *is* where the interrupt is 
recognized, and *is* where the discontinuity occurs.  Report that.

Just because some device interrupts are deferred to the end of the TB, that makes no 
difference.  There is no "right" answer for timing between execution and asynchronous 
interrupts.


r~