bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hello!

On AMD EPYC processors, as found on the build nodes of ci.guix.gnu.org,
childhurd VMs fail to boot when running with ‘qemu-system-i386
-enable-kvm’ (the kvm-amd Linux kernel module is used), with the Hurd
startup process hanging before /hurd/exec has been started:

--8<---------------cut here---------------start------------->8---
module 0: ext2fs --multiboot-command-line=${kernel-command-line} 
--host-priv-por                    
t=${host-port} --device-master-port=${device-port} 
--exec-server-task=${exec-tas                    
k} --store-type=typed --x-xattr-translator-records ${root} $(task-create) 
$(task                    
-resume)                                                                        
                    
module 1: exec 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hu               
     
rd/exec $(exec-task=task-create)                                                
                    
2 multiboot modules                                                             
                    
task loaded: ext2fs --multiboot-command-line=root=device:hd0s1 
root=3367134b-cfb                    
d-1e90-2f38-dfd13367134b 
gnu.system=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-                    
system gnu.load=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot 
--host-p                    
riv-port=1 --device-master-port=2 --exec-server-task=3 --store-type=typed 
--x-xa                    
ttr-translator-records device:hd0s1                                             
                    
task loaded: exec 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167                  
  
/hurd/exec                                                                      
                    
                                                                                
                    
start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec                  
                    
--8<---------------cut here---------------end--------------->8---

Kdb shows these two tasks:

--8<---------------cut here---------------start------------->8---
Stopped   at  mach                    
ine_idle+0x26:  nop                                                             
                    
machine_idle(0,c102f380,f5f7bcd0,c102e3fa)+0x26                                 
                    
idle_thread_continue(f5f7ade0,36366000,f5f73868,f5f73890,0)+0x73                
                    
>>>>> user space <<<<<                                                          
>>>>>                     
db> show all threads                                                            
                    
    TASK        THREADS                                                         
                    
  0 gnumach (f5f7cf00): 7 threads:                                              
                    
              0 (f5f7be18) .W..N. 0xc11dac04                                    
                    
              1 (f5f7bcd0) R.....                                               
                    
              2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4            
                    
              3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c            
                    
              4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0                      
                    
              5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74           
                    
              6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8               
                    
  1 ext2fs (f5f7ce40): 6 threads:                                               
                    
              0 (f5f7b520) .W.O.F(mach_msg_continue) 0                          
                    
              1 (f5f7b290) .W.O.F(mach_msg_receive_continue) 0                  
                    
              2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0                  
                    
              3 (f5f7b000) .W.O..(mach_msg_continue) 0                          
                    
              4 (f67d3e20) .W.O..(mach_msg_receive_continue) 0                  
                    
              5 (f67d3cd8) .W.O..(mach_msg_continue) 0                          
                    
db> trace/t 0xf5f7b520                                                          
                    
Continuation mach_msg_continue                                                  
                    
>>>>> user space <<<<<                                                          
>>>>>                     
0x80ccaec()                                                                     
                    
--8<---------------cut here---------------end--------------->8---

For ext2fs.static, that just means thread 0 is here:

--8<---------------cut here---------------start------------->8---
$ addr2line -e 
/gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hurd/ext2fs.static
 0x80ccaec
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/mach/mach_msg_trap.S:2
--8<---------------cut here---------------end--------------->8---

That doesn’t tell us much.

The same image boots fine on the same CPU without ‘-enable-kvm’.
However, keeping ‘-enable-kvm’ and adding ‘--cpu pentium’ and other
variants of this option don’t make any difference, AFAICS.

Ideas on how to debug this further, and/or ways to work around it
without giving up on KVM?

Thanks,
Ludo’.