Re: dom0 PV looping on search_pre_exception_table()

[Manuel Bouyer <bouyer@antioche.eu.org>]

On Wed, Dec 09, 2020 at 09:39:49AM +0100, Jan Beulich wrote:
> 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.

No, it's a 64bits dom0.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--