Re: port-xen/58395: panic: HYPERVISOR_mmu_update failed, ret: -22

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

I just verified that PV netbsd-11 and netbsd-current kernels both
still boot fine on Tornado with the attached patch and

options 	XEN_MAX_GRANT_FRAMES=32

in the kernel config.

We looked into this with alynpost and some Xen developers a while
back, and from what I recall, we determined:

1. Nobody could figure out why this is happening on Tornado.

2. Nobody has any idea how to detect _up front_ at runtime whether
   it's necessary (as opposed to when GNTTABOP_setup_table returns
   data).

3. It is not convenient for Tornado to apply any workaround in the
   domU's xl.conf on the host side.

Unfortunately, while we can just check for 0xfff...ff as the pfn,
doing that on the fly at runtime -- rather than deciding up front to
clamp the number of grant frames to 32 -- is difficult because we have
to unwind some state that's troublesome at that point.

# HG changeset patch
# User Taylor R Campbell <riastradh%NetBSD.org@localhost>
# Date 1792725727 0
#      Fri Oct 23 03:22:07 2026 +0000
# Branch trunk
# Node ID e7665339e42ad99f22ca2fa6931cf5dac9c42603
# Parent  adab6b9c88cde7ef98ff7436dc06bece8350063f
# EXP-Topic riastradh-pr58395-xengrantframe32tornadoworkaround
xen: New build option XEN_MAX_GRANT_FRAMES.

Provides build-time workaround for:

PR kern/58395: panic: HYPERVISOR_mmu_update failed, ret: -22

It's only a build-time workaround because I have no idea how to
detect platforms on which it is the right thing -- I only know that
it's needed on Tornado VPS, for reasons unclear.  To use this, add to
your kernel configuration:

options 	XEN_MAX_GRANT_FRAMES=32

diff -r adab6b9c88cd -r e7665339e42a sys/arch/xen/xen/xengnt.c
--- a/sys/arch/xen/xen/xengnt.c	Fri Oct 16 15:21:45 2026 +0000
+++ b/sys/arch/xen/xen/xengnt.c	Fri Oct 23 03:22:07 2026 +0000
@@ -119,6 +119,16 @@ xengnt_init(void)
 		gnt_max_grant_frames = 4; /* Legacy max number of frames */
 	else
 		gnt_max_grant_frames = query.max_nr_frames;
+#ifdef XEN_MAX_GRANT_FRAMES
+	/*
+	 * Some Xen installations give bogus grant frames beyond 32, so
+	 * we have to clamp.  No idea how to detect dynamically up
+	 * front whether to do this.
+	 *
+	 * PR port-xen/58395: panic: HYPERVISOR_mmu_update failed, ret: -22
+	 */
+	gnt_max_grant_frames = MIN(gnt_max_grant_frames, XEN_MAX_GRANT_FRAMES);
+#endif
 
 	/*
 	 * Always allocate max number of grant frames, never expand in runtime