[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dom0 PV looping on search_pre_exception_table()



On 08.12.2020 19:13, Andrew Cooper wrote:
> On 08/12/2020 17:57, Manuel Bouyer wrote:
>> Hello,
>> for the first time I tried to boot a xen kernel from devel with
>> a NetBSD PV dom0. The kernel boots, but when the first userland prcess
>> is launched, it seems to enter a loop involving search_pre_exception_table()
>> (I see an endless stream from the dprintk() at arch/x86/extable.c:202)
>>
>> With xen 4.13 I see it, but exactly once:
>> (XEN) extable.c:202: Pre-exception: ffff82d08038c304 -> ffff82d08038c8c8
>>
>> with devel:
>> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8     
>>    
>> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8     
>>    
>> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8     
>>    
>> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8     
>>    
>> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8     
>>    
>> [...]
>>
>> the dom0 kernel is the same.
>>
>> At first glance it looks like a fault in the guest is not handled at it 
>> should,
>> and the userland process keeps faulting on the same address.
>>
>> Any idea what to look at ?
> 
> That is a reoccurring fault on IRET back to guest context, and is
> probably caused by some unwise-in-hindsight cleanup which doesn't
> escalate the failure to the failsafe callback.

But is this a 32-bit Dom0? 64-bit ones get well-known selectors
installed for CS and SS by create_bounce_frame(), and we don't
permit registration of non-canonical trap handler entry point
addresses.

I have to admit I also find curious the difference between 4.13
and master.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.