Re: dom0 PV looping on search_pre_exception_table()

[Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>]

On Wed, Dec 09, 2020 at 07:08:41PM +0000, Andrew Cooper wrote:
> Oh of course - we don't follow the exit-to-guest path on the way out here.
> 
> As a gross hack to check that we've at least diagnosed the issue
> appropriately, could you modify NetBSD to explicitly load the %ss
> selector into %es (or any other free segment) before first entering user
> context?

If I understood it properly, the user %ss is loaded by Xen from the
trapframe when the guest swictes from kernel to user mode, isn't it ?
So you mean setting %es to the same value in the trapframe ?

Actually I used %fs because %es is set equal to %ds.
Xen 4.13 boots fine with this change, but with 4.15 I get a loop of:


(XEN) *** LDT: gl1e 0000000000000000 not present                               
(XEN) *** pv_map_ldt_shadow_page(0x40) failed                                  
[  12.3586540] Process (pid 1) got sig 11                                      

which means that the dom0 gets the trap, and decides that the fault address
is not mapped. Without the change the dom0 doesn't show the
"Process (pid 1) got sig 11"

I activated the NetBSD trap debug code, and this shows:
[   6.7165877] kern.module.path=/stand/amd64-xen/9.1/modules                    
(XEN) *** LDT: gl1e 0000000000000000 not present                                
(XEN) *** pv_map_ldt_shadow_page(0x40) failed                                   
[   6.9462322] pid 1.1 (init): signal 11 code=1 (trap 0x6) @rip 0x7f7ef0c007d0 a
ddr 0xffffbd800000a040 error=14
[   7.0647896] trapframe 0xffffbd80381cff00
[   7.1126288] rip 0x00007f7ef0c007d0  rsp 0x00007f7fff10aa30  rfl 0x00000000000
00202
[   7.2041518] rdi 000000000000000000  rsi 000000000000000000  rdx 0000000000000
00000
[   7.2956758] rcx 000000000000000000  r8  000000000000000000  r9  0000000000000
00000
[   7.3872013] r10 000000000000000000  r11 000000000000000000  r12 0000000000000
00000
[   7.4787216] r13 000000000000000000  r14 000000000000000000  r15 0000000000000
00000
[   7.5702439] rbp 000000000000000000  rbx 0x00007f7fff10afe0  rax 0000000000000
00000
[   7.6617663] cs 0x47  ds 0x23  es 0x23  fs 0000  gs 0000  ss 0x3f
[   7.7345663] fsbase 000000000000000000 gsbase 000000000000000000

so it looks like something resets %fs to 0 ...

Anyway the fault address 0xffffbd800000a040 is in the hypervisor's range,
isn't it ?

-- 
Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
     NetBSD: 26 ans d'experience feront toujours la difference
--