Re: [edk2-devel] [PATCH 1/1] OvmfPkg/NestedInterruptTplLib: replace ASSERT() with a warning logged.

["Gerd Hoffmann" <kraxel@redhat.com>]

On Fri, Apr 28, 2023 at 02:50:04PM +0000, Michael Brown wrote:
> On 28/04/2023 14:38, Gerd Hoffmann wrote:
> > I suspect the windows boot loader does something fishy here, but I can't
> > proof it, I have not yet pinned down the exact location where interrupts
> > get enabled while running at IPL=TPL_HIGH_LEVEL (which is what I suspect
> > is happening, but of course this is not the only possible theory how
> > that ASSERT got triggered).
> > 
> > Not fully sure how to best continue debugging this, I don't think gdb
> > can set an watchpoint on eflags.if ...
> 
> In the absence of any better ideas, I'd be tempted to run QEMU via TCG
> instead of KVM, and hack the STI instruction definition to check the
> location in guest memory where gEfiCurrentTpl gets stored in your test
> build.  (It's brute force debugging, but it should find the culprit.)

Not so easy as tcg generates code for cli+sti, so there isn't a function
I could add logging hacks to.

> From a quick check of the implementation, I'm pretty sure this will be the
> case.  However, the logic is already (necessarily) pretty complex and so I
> am not 100% sure of this.  The reasoning behind the logic in
> NestedInterruptTplLib relies on certain axioms and invariants (e.g. that
> there are a finite number of distinct TPLs, and that there are certain
> places within the code that further interrupts provably cannot occur), and
> so it gets very difficult to reason about when one of those invariants is
> violated, as it seems to be in this situation.
> 
> If it seems to work,

It seems to work, and the warning is printed exactly once during boot.

> with a warning message, and to return with InterruptedTPL unmodified. But
> I'd prefer to understand how this invariant violation arises in the first
> place.

Root cause not found yet, but all debugging so far didn't found any
problems in edk2/ovmf, so my theory still is that windows does something
fishy here.

take care,
  Gerd