Re: panic: fpudna from userland

On Sun, Apr 21, 2024 at 02:22:41PM +0000, Emmanuel Dreyfus wrote:
> Hello
> 
> On NetBSD-10.0 with XEN3PAE_DOMU kernel, I get this panic when building packages:
> [ 35714.4540347] panic: fpudna from userland, ip 0xbbe74f, trapframe 0xdbe1dfa8
> [ 35714.4540347] cpu0: Begin traceback...
> [ 35714.4540347] vpanic(c0505984,dbe1df8c,dbe1df9c,c01322bb,c0505984,c05059a8,bb
> e74f,dbe1dfa8,1a62000,bf7fc880) at netbsd:vpanic+0x18e
> [ 35714.4540347] panic(c0505984,c05059a8,bbe74f,dbe1dfa8,1a62000,bf7fc880,c0102f
> 9e,dbe1dfa8,b3,ab) at netbsd:panic+0x18
> [ 35714.4540347] fpudna(dbe1dfa8,b3,ab,bac3001f,bf7f001f,b9869d00,b98ea350,bf7fc
> 880,1a62000,0) at netbsd:fpudna+0x3b
> [ 35714.4540347] cpu0: End traceback...
> [ 35714.4540347] fatal breakpoint trap in supervisor mode
> [ 35714.4540347] trap type 1 code 0 eip 0xc0129304 cs 0x9 eflags 0x202 cr2 0xb98
> ee014 ilevel 0 esp 0xdbe1df70
> [ 35714.4540347] curlwp 0xc36ea200 pid 26009 lid 26009 lowest kstack 0xdbe1c2c0
> 
> Reading the code, the reason why we must panic here seems obscure. Anyone
> can explain? 

We're not supposed to get this trap from userland, as between -9 and -10
the lazy FPU context switching was removed; the FPU is context-switched
as other non-FPU state. As a consequence, the FPU is always enabled before
return to userland (or should) an no "FPU not available" trap should
be triggered.

I'm seeing this too for the daily anita tests from time to time.
It's hard to reproduce and didn't find a Xen-specific place were we could
fail to restore FPU context. I'm also seeing FPU-related panic for
HVM or HVM guests, and also for amd64. So I suspect it may be a bug in Xen.

-- 
Manuel Bouyer <[email protected]>
     NetBSD: 26 ans d'experience feront toujours la difference
--