Blame SOURCES/0022-lib-Disable-5-level-page-tables-when-using-cpu-max.patch

196f39
From bb19cc0cdd43619ccf830e1e608f79e46f8ddf86 Mon Sep 17 00:00:00 2001
196f39
From: "Richard W.M. Jones" <rjones@redhat.com>
196f39
Date: Thu, 12 May 2022 08:36:37 +0100
196f39
Subject: [PATCH] lib: Disable 5-level page tables when using -cpu max
196f39
196f39
In https://bugzilla.redhat.com/show_bug.cgi?id=2082806 we've been
196f39
tracking an insidious qemu bug which intermittently prevents the
196f39
libguestfs appliance from starting.  The symptoms are that SeaBIOS
196f39
starts and displays its messages, but the kernel isn't reached.  We
196f39
found that the kernel does in fact start, but when it tries to set up
196f39
page tables and jump to protected mode it gets a triple fault which
196f39
causes the emulated CPU in qemu to reset (qemu exits).
196f39
196f39
This seems to only affect TCG (not KVM).
196f39
196f39
Yesterday I found that this is caused by using -cpu max which enables
196f39
the "la57" feature (5-level page tables[0]), and that we can make the
196f39
problem go away using -cpu max,la57=off.  Note that I still don't
196f39
fully understand the qemu bug, so this is only a workaround.
196f39
196f39
I chose to disable 5-level page tables for both TCG and KVM, partly to
196f39
make the patch simpler, and partly because I guess it's not a feature
196f39
(ie. 57 bit linear addresses) that is useful for the libguestfs
196f39
appliance case, where we have limited physical memory and no need to
196f39
run any programs with huge address spaces.
196f39
196f39
I tested this by running both the direct & libvirt paths overnight.  I
196f39
expect that this patch will fail with old qemu/libvirt which doesn't
196f39
understand the "la57" feature, but this is only intended as a
196f39
temporary workaround.
196f39
196f39
[0] Article about 5-level page tables as background:
196f39
https://lwn.net/Articles/717293/
196f39
196f39
Thanks: Laszlo Ersek
196f39
Fixes: https://answers.launchpad.net/ubuntu/+source/libguestfs/+question/701625
196f39
196f39
[RHEL 8.7: Patch is not upstream.  This is the initial patch as posted
196f39
to the mailing list here:
196f39
https://listman.redhat.com/archives/libguestfs/2022-May/028853.html]
196f39
---
196f39
 lib/launch-direct.c  | 15 +++++++++++++--
196f39
 lib/launch-libvirt.c |  7 +++++++
196f39
 2 files changed, 20 insertions(+), 2 deletions(-)
196f39
196f39
diff --git a/lib/launch-direct.c b/lib/launch-direct.c
196f39
index de17d2167..6b28e4724 100644
196f39
--- a/lib/launch-direct.c
196f39
+++ b/lib/launch-direct.c
196f39
@@ -534,8 +534,19 @@ launch_direct (guestfs_h *g, void *datav, const char *arg)
196f39
   } end_list ();
196f39
 
196f39
   cpu_model = guestfs_int_get_cpu_model (has_kvm && !force_tcg);
196f39
-  if (cpu_model)
196f39
-    arg ("-cpu", cpu_model);
196f39
+  if (cpu_model) {
196f39
+#if defined(__x86_64__)
196f39
+    /* Temporary workaround for RHBZ#2082806 */
196f39
+    if (STREQ (cpu_model, "max")) {
196f39
+      start_list ("-cpu") {
196f39
+        append_list (cpu_model);
196f39
+        append_list ("la57=off");
196f39
+      } end_list ();
196f39
+    }
196f39
+    else
196f39
+#endif
196f39
+      arg ("-cpu", cpu_model);
196f39
+  }
196f39
 
196f39
   if (g->smp > 1)
196f39
     arg_format ("-smp", "%d", g->smp);
196f39
diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c
196f39
index db619910f..bad4a54ea 100644
196f39
--- a/lib/launch-libvirt.c
196f39
+++ b/lib/launch-libvirt.c
196f39
@@ -1172,6 +1172,13 @@ construct_libvirt_xml_cpu (guestfs_h *g,
196f39
       else if (STREQ (cpu_model, "max")) {
196f39
         /* https://bugzilla.redhat.com/show_bug.cgi?id=1935572#c11 */
196f39
         attribute ("mode", "maximum");
196f39
+#if defined(__x86_64__)
196f39
+        /* Temporary workaround for RHBZ#2082806 */
196f39
+        start_element ("feature") {
196f39
+          attribute ("policy", "disable");
196f39
+          attribute ("name", "la57");
196f39
+        } end_element ();
196f39
+#endif
196f39
       }
196f39
       else
196f39
         single_element ("model", cpu_model);
196f39
-- 
196f39
2.31.1
196f39