From: Shivansh Dhiman <shivansh.dhiman@amd.com>
To: <seanjc@google.com>, <pbonzini@redhat.com>
Cc: <kvm@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<corbet@lwn.net>, <skhan@linuxfoundation.org>,
<rdunlap@infradead.org>, <nikunj.dadhania@amd.com>,
<shivansh.dhiman@amd.com>
Subject: [PATCH] Documentation: KVM: x86: Update nested live migration status on AMD
Date: Thu, 8 Oct 2026 09:59:35 +0000 [thread overview]
Message-ID: <20261008095935.1237325-1-shivansh.dhiman@amd.com> (raw)
The "Live migration with nested KVM" section is stale for AMD systems
and needs an update. Migrating an SVM L1 guest with a live L2 guest in
it works, and has been tested with Linux 7.2 and QEMU 11.1.0. So,
replace the AMD-specific caveats accordingly.
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
.../virt/kvm/x86/running-nested-guests.rst | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/Documentation/virt/kvm/x86/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst
index 87326413d5c7..e41a50816058 100644
--- a/Documentation/virt/kvm/x86/running-nested-guests.rst
+++ b/Documentation/virt/kvm/x86/running-nested-guests.rst
@@ -186,21 +186,11 @@ Live migration with nested KVM
Migrating an L1 guest, with a *live* nested guest in it, to another
bare metal host, works as of Linux kernel 5.3 and QEMU 4.2.0 for
-Intel x86 systems, and even on older versions for s390x.
-
-On AMD systems, once an L1 guest has started an L2 guest, the L1 guest
-should no longer be migrated or saved (refer to QEMU documentation on
-"savevm"/"loadvm") until the L2 guest shuts down. Attempting to migrate
-or save-and-load an L1 guest while an L2 guest is running will result in
-undefined behavior. You might see a ``kernel BUG!`` entry in ``dmesg``, a
-kernel 'oops', or an outright kernel panic. Such a migrated or loaded L1
-guest can no longer be considered stable or secure, and must be restarted.
-Migrating an L1 guest merely configured to support nesting, while not
-actually running L2 guests, is expected to function normally even on AMD
-systems but may fail once guests are started.
+Intel x86 systems, and even on older versions for s390x. On AMD x86
+systems, it works with Linux kernel 7.2 and QEMU 11.1.0, or later.
Migrating an L2 guest is always expected to succeed, so all the following
-scenarios should work even on AMD systems:
+scenarios should work:
- Migrating a nested guest (L2) to another L1 guest on the *same* bare
metal host.
base-commit: 6bd2905303c58679e303941b7d8ae8c074cd95ce
--
2.43.0
reply other threads:[~2026-10-08 9:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261008095935.1237325-1-shivansh.dhiman@amd.com \
--to=shivansh.dhiman@amd.com \
--cc=corbet@lwn.net \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=rdunlap@infradead.org \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox