Re: dom0 PV looping on search_pre_exception_table()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.12.2020 10:51, Manuel Bouyer wrote:
> 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 ?

No, the hypervisor range is 0xffff800000000000-0xffff880000000000.

Jan