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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-xen/58395; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Cc: "Aaron J. Grier" <agrier%poofygoof.com@localhost>,
	Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Subject: Re: port-xen/58395: panic: HYPERVISOR_mmu_update failed, ret: -22
Date: Fri, 23 Oct 2026 03:55:02 +0000

 This is a multi-part message in MIME format.
 --=_+o6o5C5OnZRm2InKNMj9fWq1M8sr1Fxv
 
 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.
 
 --=_+o6o5C5OnZRm2InKNMj9fWq1M8sr1Fxv
 Content-Type: text/plain; charset="ISO-8859-1"; name="pr58395-xengnttabmax"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename="pr58395-xengnttabmax.patch"
 
 # 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=3D32
 
 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 =3D 4; /* Legacy max number of frames */
  	else
  		gnt_max_grant_frames =3D 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 =3D MIN(gnt_max_grant_frames, XEN_MAX_GRANT_FRAMES);
 +#endif
 =20
  	/*
  	 * Always allocate max number of grant frames, never expand in runtime
 
 --=_+o6o5C5OnZRm2InKNMj9fWq1M8sr1Fxv--