Re: Intermittent Qemu boot hang/regression traced back to INT 0x80 changes

Paul Gortmaker
2024-04-26T12:24:05Z

[Apologies for repeated info; last mail didn't make it to the list]

[Re: Intermittent Qemu boot hang/regression traced back to INT 0x80 changes] On 24/04/2024 (Wed 21:51) Borislav Petkov wrote:

> On Wed, Apr 24, 2024 at 02:58:06PM -0400, Paul Gortmaker wrote:
> ...
> > pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300 conventional PCI endpoint
> > pci 0000:00:1d.0: BAR 4 [io 0xc080-0xc09f]
> > pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300 conventional PCI endpoint
> > pci 0000:00:1d.1: BAR 4 [io 0xc0a0-0xc0bf]
> > pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300 conventional PCI endpoint
> > <hang - not always exactly here, but always in this block of PCI printk>
>
> How would those commits have anything to do with such an early hang?!
>
> Nothing that early is issuing INT80 32-bit syscalls, is it?
>
> Btw, can you checkout the Linus tree at...
>
> f35e46631b28 Merge tag 'x86-int80-20231207' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> f4116bfc4462 x86/tdx: Allow 32-bit emulation by default
>
>
> <-- here and test that commit as the top one?
>
> 55617fb991df x86/entry: Do not allow external 0x80 interrupts

They both show the issue, but that really doesn't matter now. When you
guys pointed out it really didn't make sense, I did what I should have
done before - tested the crap out of ^1, the trunk just before the
INT80 merge:

commit f35e46631b28a63ca3887d7afef1a65a5544da52
Merge: 55b224d90d44 f4116bfc4462
^^^^^^^^^^^^
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Dec 7 11:56:34 2023 -0800

Merge tag 'x86-int80-20231207' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

...which would be 55b224d90d44 (parisc merge). So I left that run
for near 24h (almost 2000 runs), and got 8 PCI-hang instances. :(
Which means INT80 isn't even there yet.

So I owe you guys an apology for pointing the finger at INT80. I still
don't understand how the pseudo bisect on v6.6-stable seems so
"concrete". The v6.6.6 worked "fine" (it seemed) and v6.6.7 died fairly
quickly. The revert of INT80 on v6.6.7 seemed to "fix" it - but if so,
it was only because it perturbed something else.

I already knew my "good" bisect points were not "proven" good, but only
statistically "good". Seems I need to revisit some of those "good" data
points (both on v6.6-stable) and on mainline and test longer.

>
> which reminds me - that hang could be actually that guest kernel
> panicking but the panic not coming out to the console.
>
> When it hangs, can you connect with gdb to qemu and dump stack and
> registers?
>
> Make sure you have DEBUG_INFO enabled in the guest kernel.

I want to try some of these things, but I also don't want to
accidentally lose the reproducer I have. Maybe I'll see if I can
reproduce it at home, since I'll lose use of the current box in a week
anyway...

Again, sorry for the false positive. I let the v6.6-stable testing bias
my mainline conclusions to where I didn't test underneath INT80. I'll
follow up with more details once (if?) I manage to properly sort this.

Paul.
--

>
> Is this even a guest?
>
> I know you had guests last time you reported the alternatives issue.
>
> Right, and then test the tree checked out at this commit:
>
> be5341eb0d43 x86/entry: Convert INT 0x80 emulation to IDTENTRY
>
> The others should be unrelated...
>
> b82a8dbd3d2f x86/coco: Disable 32-bit emulation by default on TDX and SEV
>
> Hmm.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette