From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Jan Beulich" <JBeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH] x86/cpu-policy: Fix migration from Ice Lake to Cascade Lake
Date: Tue, 7 May 2024 12:29:57 +0100 [thread overview]
Message-ID: <20240507112957.1701824-1-andrew.cooper3@citrix.com> (raw)
Ever since Xen 4.14, there has been a latent bug with migration.
While some toolstacks can level the features properly, they don't shink
feat.max_subleaf when all features have been dropped. This is because
we *still* have not completed the toolstack side work for full CPU Policy
objects.
As a consequence, even when properly feature levelled, VMs can't migrate
"backwards" across hardware which reduces feat.max_subleaf. One such example
is Ice Lake (max_subleaf=2 for INTEL_PSFD) to Cascade Lake (max_subleaf=0).
Extend the host policy's feat.max_subleaf to the hightest number Xen knows
about, similarly to how we extend extd.max_leaf for LFENCE_DISPATCH. This
will allow VMs with a higher feat.max_subleaf than strictly necessary to
migrate in.
Eventually we'll manage to teach the toolstack how to avoid creating such VMs
in the first place, but there's still more work to do there.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
xen/arch/x86/cpu-policy.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 4b6d96276399..a216fc8b886f 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -373,8 +373,13 @@ static void __init calculate_host_policy(void)
p->basic.max_leaf =
min_t(uint32_t, p->basic.max_leaf, ARRAY_SIZE(p->basic.raw) - 1);
- p->feat.max_subleaf =
- min_t(uint32_t, p->feat.max_subleaf, ARRAY_SIZE(p->feat.raw) - 1);
+
+ /*
+ * p->feat is "just" featureset information. We know about more than may
+ * be present in this hardware. Also, VMs may have a higher max_subleaf
+ * than strictly necessary, and we can accept those too.
+ */
+ p->feat.max_subleaf = ARRAY_SIZE(p->feat.raw) - 1;
max_extd_leaf = p->extd.max_leaf;
base-commit: ebab808eb1bb8f24c7d0dd41b956e48cb1824b81
--
2.30.2
next reply other threads:[~2024-05-07 11:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 11:29 Andrew Cooper [this message]
2024-05-07 11:50 ` [PATCH] x86/cpu-policy: Fix migration from Ice Lake to Cascade Lake Roger Pau Monné
2024-05-07 12:19 ` Andrew Cooper
2024-05-07 13:45 ` [PATCH v2] " Andrew Cooper
2024-05-07 14:24 ` Roger Pau Monné
2024-05-07 14:31 ` Andrew Cooper
2024-05-07 14:45 ` Roger Pau Monné
2024-05-07 15:03 ` Andrew Cooper
2024-05-14 9:40 ` Jan Beulich
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=20240507112957.1701824-1-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).