[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: dom0 PV looping on search_pre_exception_table()
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@xxxxxxxxxxxxxxx> NetBSD: 26 ans d'experience feront toujours la difference --
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |