[PATCH v2 hci-8.0/hci-8.1 0/6] i386: keep CPU features of guests from older nodes on vz machine types #VSTOR-152264

[PATCH v2 hci-8.0/hci-8.1 0/6] i386: keep CPU features of guests from older nodes on vz machine types #VSTOR-152264

[Denis V. Lunev]

A guest started on an older node can have a CPU feature that the
destination host no longer offers: TSX disabled by microcode, a newer
kernel that stops offering spec-ctrl or bus-lock-detect on AMD, or SVM
leaf features that QEMU 2.12 on Vz7 kept with svm off. QEMU filters the
feature on the destination, and libvirt refuses the live migration,
restore or snapshot revert:

  guest CPU doesn't match specification: missing features: hle,rtm

The guest read its CPUID at boot, so the bit has to stay until the guest
restarts.

Until now libvirt relaxed the check, in three places that behave
differently. One of them crashes libvirtd on the destination of any
migration of a host-passthrough VM with a vz7 machine type
(VSTOR-152247). This series keeps the bits in QEMU instead: one
x-...-compat X86CPU property per feature, all turned on by a new
pc_vz_9_2_compat on vz9.2.0 and every older vz machine type. Release
7.x ships up to vz9.1.0, and vz9.2.0 is the last type based on a RHEL 9
machine type. vz10.x types and -cpu host expansion stay strict. A
property keeps a bit only when the CPU model or the command line asks
for it and the host condition in the commit message holds; KVM ignores
CPUID bits it does not support.

Patch 1 lets a row of the vz machine type tables name a fourth compat
array, which the i440fx vz7.16.0 row needs. Patches 2 to 6 add one
property each:

  2  hle, rtm                      PSBM-149402 (field: VSTOR-75689,
                                   VSTOR-105458)
  3  spec-ctrl, AMD                VSTOR-151770
  4  bus-lock-detect, AMD          VSTOR-152291
  5  v-vmsave-vmload, AMD          code review, nested guests on Zen 4
                                   client parts, no field report
  6  SVM leaf features, svm off    PSBM-144630

The same patches apply to hci-8.0 and hci-8.1 without changes; the
base given below is hci-dev. On 8.0 they also fix the migration on
their own: hci-8.0 libvirt keeps its relaxations, and they no longer
see a filtered bit. That covers bus-lock-detect (VSTOR-152291), which
hci-8.0 libvirt does not relax. The vz7 CPU fixup there still runs on
migration (with the NULL check from VSTOR-152247) and forces npt and
nrip-save off, which the guest does not see, because leaf 0x8000000a
is hidden without svm. Only the destination needs the new qemu-kvm:
the compat acts when the incoming QEMU process starts.

On hci-dev the libvirt side drops its relaxations and the qemu.d hooks
in libvirt.ovz pr/den-VSTOR-152247-drop-vz-cpu-relaxations. It needs
this series in qemu-kvm first.

Testing:
- dev-cl04, EPYC 7443P: a saved guest whose migration cookie CPU was
  rewritten to the shape of a Vz7 host-model guest
  (svm=off,npt=on,nrip-save=on, plus spec-ctrl) fails to restore
  without the series with "missing features: npt,nrip-save" and
  "missing features: spec-ctrl". With it the guest restores, the
  features stay on and filtered-features is empty. Stock 8.1 libvirt,
  which carries the same relaxations as hci-8.0, restores it with no
  warning as well.
- sqvm2-1015, Broadwell without TSX: the VSTOR-75689 guest CPU fails
  with "missing features: hle,rtm" without the series and keeps hle
  and rtm with it.
- sqvm2-1013 <-> sqvm2-1015, with the libvirt PR: live migration in
  both directions of a pc-i440fx-vz7.12.0 host-passthrough guest and
  of the VSTOR-75689 Broadwell-IBRS guest. No crash, no warning,
  hle/rtm kept, the CPU stays match='exact'. Stock libvirt crashes on
  the first of them.
- hci-8.0 and hci-8.1 builds: -cpu EPYC-Milan,svm=off,npt=on,
  nrip-save=on,enforce and -cpu EPYC-Milan,spec-ctrl=on,enforce start
  on vz7.12.0, vz9.0.0 and vz9.2.0 and are refused on vz10.x. A fresh
  Broadwell-IBRS start with check='full' is refused on vz10.1.0.
- both builds, TCG: -cpu EPYC-Milan,svm=off warns about the same
  features on vz9.2.0 as on vz10.0.0, none from leaf 0x8000000a.
- both builds, qtest-x86_64: ivshmem-test, test-hmp and qom-test fail
  as on the base (qemu_ram_free assertion, isapc aborting at start).
- bus-lock-detect and v-vmsave-vmload are build-tested only: no Zen 5
  or Zen 4 client host was available.

Changes v1 -> v2:
- 6/6: keep SVM leaf features past the svm dependency under KVM only,
  TCG warned about them
- 2/6, 6/6, cover: commit messages clarified after the Sashiko review

v1: http://lore.virtuozzo.com/kernel/20261029095645.4173762-1-den@openvz.org/

Signed-off-by: Denis V. Lunev <den@openvz.org>

Denis V. Lunev (6):
  i386/pc: raise the limit of compat arrays per Virtuozzo machine type
    to four #VSTOR-152264
  i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0
    #PSBM-149402
  i386: keep spec-ctrl for AMD guests on vz machine types up to vz9.2.0
    #VSTOR-151770
  i386: keep bus-lock-detect for AMD guests on vz machine types up to
    vz9.2.0 #VSTOR-152291
  i386: keep v-vmsave-vmload for nested AMD guests on vz types up to
    vz9.2.0 #VSTOR-152264
  i386: keep SVM leaf features without svm on vz types up to vz9.2.0
    #PSBM-144630

 hw/i386/pc.c         |  9 ++++++
 hw/i386/pc_piix.c    |  5 ++--
 hw/i386/pc_q35.c     |  4 +--
 include/hw/i386/pc.h | 10 +++++--
 target/i386/cpu.c    | 68 +++++++++++++++++++++++++++++++++++++++++++-
 target/i386/cpu.h    | 11 +++++++
 6 files changed, 100 insertions(+), 7 deletions(-)


base-commit: 0c1497c79831c1ec8efd91d5887236963adf0f18
-- 
2.53.0

[PATCH v2 hci-8.0/hci-8.1 1/6] i386/pc: raise the limit of compat arrays per Virtuozzo machine type to four #VSTOR-152264

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

A row of VZ_Q35_MT or VZ_PC_MT can name at most three compat arrays:
COUNT_ARGS counts up to three, VZ_COMPATS_EXPAND has variants for zero
to three, and __vz_compat_props has three slots per row. No row needs
more yet, which is why the limit never showed. The i440fx vz7.16.0 row
uses all three (hw_compat_vz_9_1, hw_compat_vz_7_16,
pc_vz_7_16_compat), and the next commit adds pc_vz_9_2_compat to it.
With a fourth argument COUNT_ARGS returns that argument instead of a
count, and the build fails on an undefined VZ_COMPATS_EXPAND_<name>.

Raise the limit to four.

Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 hw/i386/pc_piix.c    | 2 +-
 hw/i386/pc_q35.c     | 2 +-
 include/hw/i386/pc.h | 7 +++++--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9a73dcfad4b..1a50c2a645c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -1087,7 +1087,7 @@ enum {
 static struct {
     GlobalProperty *prop;
     const size_t *len;
-} __vz_compat_props[][3] = {
+} __vz_compat_props[][4] = {
     { VZ_COMPATS_EXPAND(hw_compat_vz, pc_vz_compat) },
     VZ_PC_MT(AS_ARRAY)
 };
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 9bb0c7e1649..2f4a14b4e01 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -1004,7 +1004,7 @@ enum {
 static struct {
     GlobalProperty *prop;
     const size_t *len;
-} __vz_compat_props[][3] = {
+} __vz_compat_props[][4] = {
     { VZ_COMPATS_EXPAND(hw_compat_vz, pc_vz_compat) },
     VZ_Q35_MT(AS_ARRAY)
 };
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 5140c9c1f23..4d8a01528b8 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -428,8 +428,8 @@ extern const size_t pc_vz_7_4_compat_len;
 /*
  * Helper macros for defining VZ machine types, both pc and q35
  */
-#define _GET_NTH_ARG(_0, _1, _2, _3, N, ...) N
-#define COUNT_ARGS(...) _GET_NTH_ARG(__VA_ARGS__, 3, 2, 1, 0)
+#define _GET_NTH_ARG(_0, _1, _2, _3, _4, N, ...) N
+#define COUNT_ARGS(...) _GET_NTH_ARG(__VA_ARGS__, 4, 3, 2, 1, 0)
 
 #define VZ_COMPATS_EXPAND_0()
 #define VZ_COMPATS_EXPAND_1(prop1) {prop1, &prop1##_len}
@@ -437,6 +437,9 @@ extern const size_t pc_vz_7_4_compat_len;
     {prop1, &prop1##_len}, {prop2, &prop2##_len}
 #define VZ_COMPATS_EXPAND_3(prop1, prop2, prop3)  \
     {prop1, &prop1##_len}, {prop2, &prop2##_len}, {prop3, &prop3##_len}
+#define VZ_COMPATS_EXPAND_4(prop1, prop2, prop3, prop4)  \
+    {prop1, &prop1##_len}, {prop2, &prop2##_len}, {prop3, &prop3##_len}, \
+    {prop4, &prop4##_len}
 
 #define VZ_COMPATS_EXPAND_N(n, ...) VZ_COMPATS_EXPAND_##n(__VA_ARGS__)
 #define VZ_COMPATS_EXPAND_(n, ...)  VZ_COMPATS_EXPAND_N(n, __VA_ARGS__)
-- 
2.53.0

[PATCH v2 hci-8.0/hci-8.1 2/6] i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0 #PSBM-149402

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

Intel microcode updates for TAA disable TSX, and a host may also boot
with tsx=off. KVM then stops offering hle and rtm, QEMU filters them,
and a guest started with TSX can no longer be migrated, restored or
reverted to a snapshot on that host: libvirt rejects the filtered
features (VSTOR-75689, VSTOR-105458). The guest read its CPUID at
boot, so the bits have to stay until it is restarted.

Add x-tsx-compat: hle and rtm requested by an Intel CPU model or on
the command line are then not filtered, and KVM gets them in the guest
CPUID, ignoring bits it does not support. This also covers Haswell
parts with the TSX erratum, where QEMU drops the bits itself and the
erratum microcode disables TSX. With TSX disabled by microcode XBEGIN
aborts and HLE prefixes are ignored, so a guest that keeps using TSX
falls back to its lock path. Where TSX_CTRL disables TSX instead,
XBEGIN raises #UD, as it does with the libvirt relaxation this
replaces.

As a machine type property it also applies when such a guest is booted
afresh: it gets the CPUID it had on the older node, not a filtered one.
Limiting it to -incoming would make the CPUID depend on how the process
was started, and a cold boot with libvirt check='full' would fail on a
host without TSX. A guest that migrated in already runs with the bits,
so the cold boot adds no new failure mode. The kept bits are not
reported as filtered, so check and enforce stay silent for them.

pc_vz_9_2_compat turns it on for vz9.2.0 and every older vz machine
type. Release 7.x ships up to vz9.1.0, and vz9.2.0 is the last type
based on a RHEL 9 machine type, before the QEMU 10 based vz10.x types.
vz10.x types and -cpu host expansion stay strict.

Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 hw/i386/pc.c         |  5 +++++
 hw/i386/pc_piix.c    |  3 ++-
 hw/i386/pc_q35.c     |  2 +-
 include/hw/i386/pc.h |  3 +++
 target/i386/cpu.c    | 27 ++++++++++++++++++++++++++-
 target/i386/cpu.h    |  7 +++++++
 6 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 76289b86c28..25b17866103 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -548,6 +548,11 @@ GlobalProperty pc_vz_compat[] = {
 };
 const size_t pc_vz_compat_len = G_N_ELEMENTS(pc_vz_compat);
 
+GlobalProperty pc_vz_9_2_compat[] = {
+    { TYPE_X86_CPU, "x-tsx-compat", "on" },
+};
+const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
+
 GlobalProperty pc_vz_7_16_compat[] = {
     { TYPE_X86_CPU, "kvm-pv-ipi", "off" },
     { TYPE_X86_CPU, "kvm-pv-tlb-flush", "off" },
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 1a50c2a645c..5be7c2ab967 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -1060,7 +1060,8 @@ DEFINE_I440FX_RHEL_MACHINE(7, 2, 0);
     X(10, 0, 0, MT_VER_SYM(10, 0, 0), false)                                \
     X(7, 16, 0, MT_VER_SYM(7, 6, 0),  false, hw_compat_vz_9_1,              \
                                              hw_compat_vz_7_16,             \
-                                             pc_vz_7_16_compat)             \
+                                             pc_vz_7_16_compat,             \
+                                             pc_vz_9_2_compat)              \
     X(7, 12, 0, MT_VER_SYM(7, 6, 0),  false, hw_compat_vz_7_12)             \
     X(7, 10, 0, MT_VER_SYM(7, 6, 0),  false, hw_compat_vz_7_10)             \
     X(7, 8,  0, MT_VER_SYM(7, 5, 0),  false)                                \
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 2f4a14b4e01..019239bec6a 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -974,7 +974,7 @@ DEFINE_Q35_RHEL_MACHINE(7, 3, 0);
 #define VZ_Q35_MT(X)                                                        \
     X(10, 1, 0, MT_VER_SYM(10, 2, 0), true)                                 \
     X(10, 0, 0, MT_VER_SYM(10, 0, 0), false)                                \
-    X(9, 2,  0, MT_VER_SYM(9, 6, 0),  false)                                \
+    X(9, 2,  0, MT_VER_SYM(9, 6, 0),  false, pc_vz_9_2_compat)              \
     X(9, 1,  0, MT_VER_SYM(9, 4, 0),  false, hw_compat_vz_9_1)              \
     X(9, 0,  0, MT_VER_SYM(9, 2, 0),  false)                                \
     X(7, 16, 0, MT_VER_SYM(7, 6, 0),  false, hw_compat_vz_7_16,             \
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 4d8a01528b8..bd73426644e 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -364,6 +364,9 @@ extern const size_t pc_rhel_7_2_compat_len;
 extern GlobalProperty pc_vz_compat[];
 extern const size_t pc_vz_compat_len;
 
+extern GlobalProperty pc_vz_9_2_compat[];
+extern const size_t pc_vz_9_2_compat_len;
+
 extern GlobalProperty pc_vz_7_16_compat[];
 extern const size_t pc_vz_7_16_compat_len;
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5310d68443b..5ff5644dee9 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -9100,6 +9100,29 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
     }
 }
 
+/* Requested features that a vz compat property keeps despite the host */
+static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
+{
+    CPUX86State *env = &cpu->env;
+    uint64_t kept = 0;
+
+    if (!kvm_enabled()) {
+        return 0;
+    }
+
+    switch (w) {
+    case FEAT_7_0_EBX:
+        if (cpu->tsx_compat && IS_INTEL_CPU(env)) {
+            kept = CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_RTM;
+        }
+        break;
+    default:
+        break;
+    }
+
+    return kept & env->features[w];
+}
+
 /*
  * Finishes initialization of CPUID data, filters CPU feature
  * words based on host availability of each feature.
@@ -9126,7 +9149,8 @@ static bool x86_cpu_filter_features(X86CPU *cpu, bool verbose)
         uint64_t host_feat =
             x86_cpu_get_supported_feature_word(NULL, w);
         uint64_t requested_features = env->features[w];
-        uint64_t unavailable_features = requested_features & ~host_feat;
+        uint64_t unavailable_features = requested_features & ~host_feat &
+            ~x86_cpu_compat_kept_features(cpu, w);
         mark_unavailable_features(cpu, w, unavailable_features, prefix);
     }
 
@@ -10056,6 +10080,7 @@ static const Property x86_cpu_properties[] = {
                      arch_cap_always_on, false),
     DEFINE_PROP_BOOL("x-pdcm-on-even-without-pmu", X86CPU,
                      pdcm_on_even_without_pmu, false),
+    DEFINE_PROP_BOOL("x-tsx-compat", X86CPU, tsx_compat, false),
 };
 
 #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 07b7a9417b1..85efd0b9fbe 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2331,6 +2331,13 @@ struct ArchCPU {
      */
     bool pdcm_on_even_without_pmu;
 
+    /*
+     * Virtuozzo machine types up to vz9.2.0: do not filter requested
+     * features the host no longer provides, so that a guest started on an
+     * older node keeps its CPUID.
+     */
+    bool tsx_compat;
+
     /* Number of physical address bits supported */
     uint32_t phys_bits;
 
-- 
2.53.0

[PATCH v2 hci-8.0/hci-8.1 3/6] i386: keep spec-ctrl for AMD guests on vz machine types up to vz9.2.0 #VSTOR-151770

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

Since kernel commit de572491a975 ("KVM: x86: AMD's IBPB is not
equivalent to Intel's IBPB") KVM offers spec-ctrl on AMD hosts only
with IBPB_RET, which Zen 1-3 lack. A guest started under an older
kernel has spec-ctrl in its CPUID, and QEMU filters it on the new
host, so migration, restore and snapshot revert fail (VSTOR-151770).

Add x-spec-ctrl-compat and turn it on in pc_vz_9_2_compat: an AMD
guest keeps a requested spec-ctrl when the host still provides
amd-ibpb and one of amd-ibrs, amd-stibp and amd-ssbd. KVM then keeps
MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD available to the guest
through those bits (kernel commits 39485ed95d6b, 841c2be09fe4).

Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 hw/i386/pc.c      |  1 +
 target/i386/cpu.c | 14 ++++++++++++++
 target/i386/cpu.h |  1 +
 3 files changed, 16 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 25b17866103..95ff2e7860e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -550,6 +550,7 @@ const size_t pc_vz_compat_len = G_N_ELEMENTS(pc_vz_compat);
 
 GlobalProperty pc_vz_9_2_compat[] = {
     { TYPE_X86_CPU, "x-tsx-compat", "on" },
+    { TYPE_X86_CPU, "x-spec-ctrl-compat", "on" },
 };
 const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5ff5644dee9..872c00fc983 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -9116,6 +9116,19 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
             kept = CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_RTM;
         }
         break;
+    case FEAT_7_0_EDX:
+        if (cpu->spec_ctrl_compat && IS_AMD_CPU(env)) {
+            uint32_t ebx = kvm_arch_get_supported_cpuid(kvm_state, 0x80000008,
+                                                        0, R_EBX);
+
+            if ((ebx & CPUID_8000_0008_EBX_IBPB) &&
+                (ebx & (CPUID_8000_0008_EBX_IBRS |
+                        CPUID_8000_0008_EBX_STIBP |
+                        CPUID_8000_0008_EBX_AMD_SSBD))) {
+                kept = CPUID_7_0_EDX_SPEC_CTRL;
+            }
+        }
+        break;
     default:
         break;
     }
@@ -10081,6 +10094,7 @@ static const Property x86_cpu_properties[] = {
     DEFINE_PROP_BOOL("x-pdcm-on-even-without-pmu", X86CPU,
                      pdcm_on_even_without_pmu, false),
     DEFINE_PROP_BOOL("x-tsx-compat", X86CPU, tsx_compat, false),
+    DEFINE_PROP_BOOL("x-spec-ctrl-compat", X86CPU, spec_ctrl_compat, false),
 };
 
 #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 85efd0b9fbe..740fb3aedc5 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2337,6 +2337,7 @@ struct ArchCPU {
      * older node keeps its CPUID.
      */
     bool tsx_compat;
+    bool spec_ctrl_compat;
 
     /* Number of physical address bits supported */
     uint32_t phys_bits;
-- 
2.53.0

[PATCH v2 hci-8.0/hci-8.1 4/6] i386: keep bus-lock-detect for AMD guests on vz machine types up to vz9.2.0 #VSTOR-152291

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

Since kernel commit 54950bfe2b69 KVM on AMD no longer offers
bus-lock-detect. A Zen 5 guest started under an older kernel has it in
its CPUID, and QEMU filters it on the new host, so migration, restore
and snapshot revert fail (VSTOR-152291).

Add x-bus-lock-detect-compat and turn it on in pc_vz_9_2_compat: an
AMD guest keeps a requested bus-lock-detect. The guest loses nothing
it had: bus lock detection did not work under KVM on AMD before kernel
commit 62ad461079e7, DR6 bit 11 stays fixed, and a Linux 6.13 or newer
guest only logs one "unchecked MSR access" warning when it brings a
vCPU online.

Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 hw/i386/pc.c      | 1 +
 target/i386/cpu.c | 7 +++++++
 target/i386/cpu.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 95ff2e7860e..91198e8996c 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -551,6 +551,7 @@ const size_t pc_vz_compat_len = G_N_ELEMENTS(pc_vz_compat);
 GlobalProperty pc_vz_9_2_compat[] = {
     { TYPE_X86_CPU, "x-tsx-compat", "on" },
     { TYPE_X86_CPU, "x-spec-ctrl-compat", "on" },
+    { TYPE_X86_CPU, "x-bus-lock-detect-compat", "on" },
 };
 const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 872c00fc983..84abaf1ae31 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -9116,6 +9116,11 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
             kept = CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_RTM;
         }
         break;
+    case FEAT_7_0_ECX:
+        if (cpu->bus_lock_detect_compat && IS_AMD_CPU(env)) {
+            kept = CPUID_7_0_ECX_BUS_LOCK_DETECT;
+        }
+        break;
     case FEAT_7_0_EDX:
         if (cpu->spec_ctrl_compat && IS_AMD_CPU(env)) {
             uint32_t ebx = kvm_arch_get_supported_cpuid(kvm_state, 0x80000008,
@@ -10095,6 +10100,8 @@ static const Property x86_cpu_properties[] = {
                      pdcm_on_even_without_pmu, false),
     DEFINE_PROP_BOOL("x-tsx-compat", X86CPU, tsx_compat, false),
     DEFINE_PROP_BOOL("x-spec-ctrl-compat", X86CPU, spec_ctrl_compat, false),
+    DEFINE_PROP_BOOL("x-bus-lock-detect-compat", X86CPU,
+                     bus_lock_detect_compat, false),
 };
 
 #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 740fb3aedc5..b5e2d88d5d5 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2338,6 +2338,7 @@ struct ArchCPU {
      */
     bool tsx_compat;
     bool spec_ctrl_compat;
+    bool bus_lock_detect_compat;
 
     /* Number of physical address bits supported */
     uint32_t phys_bits;
-- 
2.53.0

[PATCH v2 hci-8.0/hci-8.1 5/6] i386: keep v-vmsave-vmload for nested AMD guests on vz types up to vz9.2.0 #VSTOR-152264

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

On Zen 4 client parts (family 19h models 0x18-0x1f and 0x60-0x7f) the
6.12 kernel clears virtualized VMSAVE/VMLOAD in init_amd_zen4(), which
some BIOSes trigger on reboot, and KVM stops offering v-vmsave-vmload.
A nested guest (svm=on) started before has it in its CPUID, and QEMU
filters it on such a host, so migration, restore and snapshot revert
fail.

Add x-v-vmsave-vmload-compat and turn it on in pc_vz_9_2_compat: an
AMD guest keeps a requested v-vmsave-vmload. This does not turn host
VLS back on: KVM keeps intercepting VMLOAD and VMSAVE of the nested
guest and emulates them (nested_vmcb_needs_vls_intercept()), which is
only slower.

Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 hw/i386/pc.c      | 1 +
 target/i386/cpu.c | 7 +++++++
 target/i386/cpu.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 91198e8996c..5b2b2de4064 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -552,6 +552,7 @@ GlobalProperty pc_vz_9_2_compat[] = {
     { TYPE_X86_CPU, "x-tsx-compat", "on" },
     { TYPE_X86_CPU, "x-spec-ctrl-compat", "on" },
     { TYPE_X86_CPU, "x-bus-lock-detect-compat", "on" },
+    { TYPE_X86_CPU, "x-v-vmsave-vmload-compat", "on" },
 };
 const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 84abaf1ae31..52d7ffcb9ac 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -9134,6 +9134,11 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
             }
         }
         break;
+    case FEAT_SVM:
+        if (cpu->v_vmsave_vmload_compat && IS_AMD_CPU(env)) {
+            kept = CPUID_SVM_V_VMSAVE_VMLOAD;
+        }
+        break;
     default:
         break;
     }
@@ -10102,6 +10107,8 @@ static const Property x86_cpu_properties[] = {
     DEFINE_PROP_BOOL("x-spec-ctrl-compat", X86CPU, spec_ctrl_compat, false),
     DEFINE_PROP_BOOL("x-bus-lock-detect-compat", X86CPU,
                      bus_lock_detect_compat, false),
+    DEFINE_PROP_BOOL("x-v-vmsave-vmload-compat", X86CPU,
+                     v_vmsave_vmload_compat, false),
 };
 
 #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index b5e2d88d5d5..4f8bcbe600a 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2339,6 +2339,7 @@ struct ArchCPU {
     bool tsx_compat;
     bool spec_ctrl_compat;
     bool bus_lock_detect_compat;
+    bool v_vmsave_vmload_compat;
 
     /* Number of physical address bits supported */
     uint32_t phys_bits;
-- 
2.53.0

[PATCH v2 hci-8.0/hci-8.1 6/6] i386: keep SVM leaf features without svm on vz types up to vz9.2.0 #PSBM-144630

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

Since commit 730319aef0f ("i386: Mask SVM features if nested SVM is
disabled", QEMU 5.1) the features of CPUID leaf 0x8000000a are dropped
when svm is off. QEMU 2.12 on Vz7 kept them, and a Vz7 host-model
guest runs with svm=off,npt=on,nrip-save=on. Moving it to a newer QEMU
fails in libvirt (PSBM-144630):

  guest CPU doesn't match specification: missing features: npt,nrip-save

Add x-svm-features-compat and turn it on in pc_vz_9_2_compat: under KVM
requested SVM leaf features stay when svm is off, both against the
dependency on svm and against the host. The guest sees the CPUID it
saw on QEMU 2.12: cpu_x86_cpuid() reports leaf 0x8000000a only with
svm, and the kept features raise the automatic xlevel to 0x8000000a
as they did there. TCG keeps dropping the features, since it cannot
provide them.

Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 hw/i386/pc.c      |  1 +
 target/i386/cpu.c | 13 +++++++++++++
 target/i386/cpu.h |  1 +
 3 files changed, 15 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5b2b2de4064..9b6b51bd5f7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -553,6 +553,7 @@ GlobalProperty pc_vz_9_2_compat[] = {
     { TYPE_X86_CPU, "x-spec-ctrl-compat", "on" },
     { TYPE_X86_CPU, "x-bus-lock-detect-compat", "on" },
     { TYPE_X86_CPU, "x-v-vmsave-vmload-compat", "on" },
+    { TYPE_X86_CPU, "x-svm-features-compat", "on" },
 };
 const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 52d7ffcb9ac..3b541ecc65e 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -8996,6 +8996,13 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
 
     for (i = 0; i < ARRAY_SIZE(feature_dependencies); i++) {
         FeatureDep *d = &feature_dependencies[i];
+
+        /* CPUID leaf 0x8000000a stays empty without svm anyway */
+        if (cpu->svm_features_compat && kvm_enabled() &&
+            d->to.index == FEAT_SVM) {
+            continue;
+        }
+
         if (!(env->features[d->from.index] & d->from.mask)) {
             uint64_t unavailable_features = env->features[d->to.index] & d->to.mask;
 
@@ -9138,6 +9145,10 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
         if (cpu->v_vmsave_vmload_compat && IS_AMD_CPU(env)) {
             kept = CPUID_SVM_V_VMSAVE_VMLOAD;
         }
+        if (cpu->svm_features_compat &&
+            !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM)) {
+            kept = ~0ULL;
+        }
         break;
     default:
         break;
@@ -10109,6 +10120,8 @@ static const Property x86_cpu_properties[] = {
                      bus_lock_detect_compat, false),
     DEFINE_PROP_BOOL("x-v-vmsave-vmload-compat", X86CPU,
                      v_vmsave_vmload_compat, false),
+    DEFINE_PROP_BOOL("x-svm-features-compat", X86CPU,
+                     svm_features_compat, false),
 };
 
 #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 4f8bcbe600a..97e38013e46 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2340,6 +2340,7 @@ struct ArchCPU {
     bool spec_ctrl_compat;
     bool bus_lock_detect_compat;
     bool v_vmsave_vmload_compat;
+    bool svm_features_compat;
 
     /* Number of physical address bits supported */
     uint32_t phys_bits;
-- 
2.53.0

Re: [PATCH v2 hci-8.0/hci-8.1 1/6] i386/pc: raise the limit of compat arrays per Virtuozzo machine type to four #VSTOR-152264

[no-reply]

> From: Denis V. Lunev <den@openvz.org>
> 
> A row of VZ_Q35_MT or VZ_PC_MT can name at most three compat arrays:
> COUNT_ARGS counts up to three, VZ_COMPATS_EXPAND has variants for zero
> to three, and __vz_compat_props has three slots per row. No row needs
> more yet, which is why the limit never showed. The i440fx vz7.16.0 row
> uses all three (hw_compat_vz_9_1, hw_compat_vz_7_16,
> pc_vz_7_16_compat), and the next commit adds pc_vz_9_2_compat to it.
> With a fourth argument COUNT_ARGS returns that argument instead of a
> count, and the build fails on an undefined VZ_COMPATS_EXPAND_<name>.
> 
> Raise the limit to four.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261029113436.93521-1-den@openvz.org?part=1

Re: [PATCH v2 hci-8.0/hci-8.1 3/6] i386: keep spec-ctrl for AMD guests on vz machine types up to vz9.2.0 #VSTOR-151770

[no-reply]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] i386: spec-ctrl compat checks host AMD bits, not the guest's own AMD bits
- [Low] i386: spec_ctrl_compat field sits under the TSX-only comment with no doc
- [Low] i386: spec-ctrl compat keyed on guest vendor, not covering Intel models on AMD hosts
--

commit 345ccab3ac1f9c86d5966e00d0e21318a3f7dff4
Author: Denis V. Lunev <den@openvz.org>

i386: keep spec-ctrl for AMD guests on vz machine types up to vz9.2.0

This patch adds the x-spec-ctrl-compat CPU property and enables it in
pc_vz_9_2_compat. When it is set, an AMD guest keeps a requested spec-ctrl
if the host reports amd-ibpb and one of amd-ibrs, amd-stibp or amd-ssbd.
This avoids spec-ctrl being filtered on hosts where KVM no longer offers it
without IBPB_RET.

> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c

[ ... ]

> @@ -9116,6 +9116,19 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
>              kept = CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_RTM;
>          }
>          break;
> +    case FEAT_7_0_EDX:
> +        if (cpu->spec_ctrl_compat && IS_AMD_CPU(env)) {
> +            uint32_t ebx = kvm_arch_get_supported_cpuid(kvm_state, 0x80000008,
> +                                                        0, R_EBX);
> +
> +            if ((ebx & CPUID_8000_0008_EBX_IBPB) &&
> +                (ebx & (CPUID_8000_0008_EBX_IBRS |
> +                        CPUID_8000_0008_EBX_STIBP |
> +                        CPUID_8000_0008_EBX_AMD_SSBD))) {
> +                kept = CPUID_7_0_EDX_SPEC_CTRL;

[Severity: Medium]
Can spec-ctrl be kept for a guest that does not itself carry the AMD
bits? The condition in x86_cpu_compat_kept_features() reads only the
host-supported bits from kvm_arch_get_supported_cpuid() for 0x80000008
EBX. It never looks at env->features[FEAT_8000_0008_EBX].

In x86_cpu_filter_features() the guest's FEAT_8000_0008_EBX is filtered
independently, and the kept bit bypasses the host-support filter:

    uint64_t unavailable_features = requested_features & ~host_feat &
        ~x86_cpu_compat_kept_features(cpu, w);

A guest with x-spec-ctrl-compat=on and spec-ctrl requested, but lacking
amd-ibpb or all of amd-ibrs, amd-stibp and amd-ssbd, could keep spec-ctrl
in CPUID. KVM might then leave MSR_IA32_SPEC_CTRL or MSR_IA32_PRED_CMD
unavailable to that guest, so a guest wrmsr would take #GP.

This relies on the KVM behaviour described in the cited kernel commits,
which I could not verify in this tree. Should the check also test the
guest's own FEAT_8000_0008_EBX bits? The later patches in the series do
not change this case.

> +            }
> +        }
> +        break;

[Severity: Low]
Is the IS_AMD_CPU(env) gate too narrow? It tests the guest CPUID vendor,
not the host vendor. For an Intel-vendor guest model on an AMD host,
kept stays 0 in x86_cpu_compat_kept_features(), so
x86_cpu_filter_features() still marks spec-ctrl unavailable:

    uint64_t unavailable_features = requested_features & ~host_feat &
        ~x86_cpu_compat_kept_features(cpu, w);

The existing Intel models set CPUID_7_0_EDX_SPEC_CTRL, and nothing in
this tree forces the guest vendor to match the host vendor. Such a guest
would hit the same migration, restore and snapshot revert failure
described in the commit message. Is it intended that Hygon guests and
Intel-vendor models on AMD hosts are left out? The series-final state
keeps the same IS_AMD_CPU(env) gate.

[ ... ]

> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -2337,6 +2337,7 @@ struct ArchCPU {
>       * older node keeps its CPUID.
>       */
>      bool tsx_compat;
> +    bool spec_ctrl_compat;

[Severity: Low]
This isn't a bug, but the new spec_ctrl_compat field is placed directly
under the comment that describes tsx_compat, so that comment appears to
cover it as well. Could it get its own comment describing the AMD
spec-ctrl behaviour?

>  
>      /* Number of physical address bits supported */
>      uint32_t phys_bits;

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261029113436.93521-1-den@openvz.org?part=3

Re: [PATCH v2 hci-8.0/hci-8.1 2/6] i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0 #PSBM-149402

[no-reply]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] i386: x-tsx-compat advertises HLE/RTM on cold boot even when host TSX is off
- [Low] i386: x-tsx-compat keeps HLE/RTM on Haswell hosts without checking microcode
--

commit dbdfc9450553c67e1ff2b80314cb5e7632457006
Author: Denis V. Lunev <den@openvz.org>

i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0 #PSBM-149402

This commit adds an x-tsx-compat CPU property. When it is on, hle and rtm
requested by an Intel CPU model are not filtered against host support under
KVM. The property is enabled through pc_vz_9_2_compat for vz9.2.0 and older
vz machine types, so that a guest that booted with TSX can still be migrated
to a host where TSX is disabled.

> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c

[ ... ]

> +GlobalProperty pc_vz_9_2_compat[] = {
> +    { TYPE_X86_CPU, "x-tsx-compat", "on" },
> +};
> +const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);

[Severity: Medium]
Because this is a machine type default, it applies to cold boot as well as
to incoming migration. Can this make a freshly started guest see hle and
rtm in CPUID on a host where TSX is off?

Where the host disables TSX through TSX_CTRL (tsx=off or the TAA default),
XBEGIN raises #UD, as the commit message says. A guest that trusts CPUID,
for example through lock elision or a TSX-aware library, could then take
SIGILL or a guest kernel fault.

Previously a fresh guest on such a host booted with these bits filtered.
For a cold boot this looks like new exposure. The statement that "the cold
boot adds no new failure mode" only seems to hold for guests that already
ran with the bits on another node.

Would it be possible to limit the behaviour to incoming migration? Or could
the code check how the host disabled TSX?

> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c

[ ... ]

> +static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
> +{

[ ... ]

> +    switch (w) {
> +    case FEAT_7_0_EBX:
> +        if (cpu->tsx_compat && IS_INTEL_CPU(env)) {
> +            kept = CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_RTM;
> +        }
> +        break;

[Severity: Medium]
The only conditions here are kvm_enabled(), tsx_compat and IS_INTEL_CPU().
Nothing checks for incoming migration or for the way the host disabled TSX.

x86_cpu_filter_features() subtracts this result from unavailable_features,
so hle and rtm stay in env->features[FEAT_7_0_EBX]. They are not recorded
through mark_unavailable_features(), so check and enforce stay silent.

The existing masking in kvm_arch_get_supported_cpuid() only runs when host
TSX is broken (the host_tsx_broken() branch that clears RTM and HLE). It
affects the supported-CPUID query and not the guest CPUID. Is anything in
kvm.c expected to mask these bits again before they reach KVM_SET_CPUID2?

I could not confirm how the kernel handles these bits in KVM_SET_CPUID2.

[Severity: Low]
There is a second question about Haswell hosts with the TSX erratum. In
kvm_arch_get_supported_cpuid(), host_tsx_broken() hides RTM and HLE. It
looks only at family, model and stepping, and it reads no microcode
revision.

With x-tsx-compat on, x86_cpu_compat_kept_features() returns HLE and RTM
for any Intel guest, regardless of host state. How does the code tell
"erratum microcode has disabled TSX" apart from "erratum part with TSX still
active"?

The commit message says the "erratum microcode disables TSX" on these parts.
Is there code or documentation that backs up that assumption? Without it, a
guest could see TSX enabled on silicon with the known erratum, and no
check/enforce warning would be printed.

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261029113436.93521-1-den@openvz.org?part=2

Re: [PATCH v2 hci-8.0/hci-8.1 4/6] i386: keep bus-lock-detect for AMD guests on vz machine types up to vz9.2.0 #VSTOR-152291

[no-reply]

> From: Denis V. Lunev <den@openvz.org>
> 
> Since kernel commit 54950bfe2b69 KVM on AMD no longer offers
> bus-lock-detect. A Zen 5 guest started under an older kernel has it in
> its CPUID, and QEMU filters it on the new host, so migration, restore
> and snapshot revert fail (VSTOR-152291).
> 
> Add x-bus-lock-detect-compat and turn it on in pc_vz_9_2_compat: an
> AMD guest keeps a requested bus-lock-detect. The guest loses nothing
> it had: bus lock detection did not work under KVM on AMD before kernel
> commit 62ad461079e7, DR6 bit 11 stays fixed, and a Linux 6.13 or newer
> guest only logs one "unchecked MSR access" warning when it brings a
> vCPU online.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261029113436.93521-1-den@openvz.org?part=4

Re: [PATCH v2 hci-8.0/hci-8.1 5/6] i386: keep v-vmsave-vmload for nested AMD guests on vz types up to vz9.2.0 #VSTOR-152264

[no-reply]

> From: Denis V. Lunev <den@openvz.org>
> 
> On Zen 4 client parts (family 19h models 0x18-0x1f and 0x60-0x7f) the
> 6.12 kernel clears virtualized VMSAVE/VMLOAD in init_amd_zen4(), which
> some BIOSes trigger on reboot, and KVM stops offering v-vmsave-vmload.
> A nested guest (svm=on) started before has it in its CPUID, and QEMU
> filters it on such a host, so migration, restore and snapshot revert
> fail.
> 
> Add x-v-vmsave-vmload-compat and turn it on in pc_vz_9_2_compat: an
> AMD guest keeps a requested v-vmsave-vmload. This does not turn host
> VLS back on: KVM keeps intercepting VMLOAD and VMSAVE of the nested
> guest and emulates them (nested_vmcb_needs_vls_intercept()), which is
> only slower.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261029113436.93521-1-den@openvz.org?part=5

Re: [PATCH v2 hci-8.0/hci-8.1 6/6] i386: keep SVM leaf features without svm on vz types up to vz9.2.0 #PSBM-144630

[no-reply]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] i386: svm-features-compat keeps all FEAT_SVM bits, not only requested ones
--

commit 9fd87512847e5481366616a7120c63227cf34e0f
Author: Denis V. Lunev <den@openvz.org>

i386: keep SVM leaf features without svm on vz types up to vz9.2.0 #PSBM-144630

This commit adds the x-svm-features-compat CPU property and enables it in
pc_vz_9_2_compat. Under KVM, SVM leaf features (CPUID 0x8000000a) are kept
when svm is off, both against the svm dependency and against the host.

> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c

[ ... ]

> @@ -8996,6 +8996,13 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
>  
>      for (i = 0; i < ARRAY_SIZE(feature_dependencies); i++) {
>          FeatureDep *d = &feature_dependencies[i];
> +
> +        /* CPUID leaf 0x8000000a stays empty without svm anyway */
> +        if (cpu->svm_features_compat && kvm_enabled() &&
> +            d->to.index == FEAT_SVM) {
> +            continue;
> +        }
> +

[Severity: Low]
The commit message says that "requested SVM leaf features stay when svm is
off". Does this skip go further than that?

This continue applies to every FEAT_SVM dependency entry. In
x86_cpu_expand_features(), when xcc->max_features is set (-cpu host or
-cpu max), the earlier loop ORs x86_cpu_get_supported_feature_word() into
env->features[FEAT_SVM] for bits the user did not set.

With svm=off on an AMD KVM host with nested SVM, those host-derived bits are
no longer cleared by the svm dependency.

The skip also bypasses mark_unavailable_features() for explicitly requested
SVM leaf features.

>          if (!(env->features[d->from.index] & d->from.mask)) {
>              uint64_t unavailable_features = env->features[d->to.index] & d->to.mask;

[ ... ]

> @@ -9138,6 +9145,10 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
>          if (cpu->v_vmsave_vmload_compat && IS_AMD_CPU(env)) {
>              kept = CPUID_SVM_V_VMSAVE_VMLOAD;
>          }
> +        if (cpu->svm_features_compat &&
> +            !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM)) {
> +            kept = ~0ULL;
> +        }
>          break;

Is it intended that kept = ~0ULL keeps every FEAT_SVM bit against the host?

The result is masked only with env->features[w]. Nothing limits it to
explicitly requested bits, and there is no IS_AMD_CPU() check. The
neighbouring compat cases use IS_AMD_CPU() or IS_INTEL_CPU().

As a result, x86_cpu_adjust_feat_level(cpu, FEAT_SVM) can see a non-zero
env->features[FEAT_SVM] and raise cpuid_min_xlevel to 0x8000000a. The kept
bits can also show up in the QOM feature properties and in
query-cpu-model-expansion.

Guest CPUID leaf 0x8000000a itself stays zero, since cpu_x86_cpuid() returns
zeros without svm. Would it make sense to restrict the kept mask to
env->user_features[FEAT_SVM] and to add a vendor check, so the behaviour
matches the commit message?

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261029113436.93521-1-den@openvz.org?part=6

Re: [PATCH v2 hci-8.0/hci-8.1 1/6] i386/pc: raise the limit of compat arrays per Virtuozzo machine type to four #VSTOR-152264

[Andrey Drobyshev]

On Thu, 29 Oct 2026 12:34:31 +0100, Denis V. Lunev <den@openvz.org> wrote:
> A row of VZ_Q35_MT or VZ_PC_MT can name at most three compat arrays:
> COUNT_ARGS counts up to three, VZ_COMPATS_EXPAND has variants for zero
> to three, and __vz_compat_props has three slots per row. No row needs
> more yet, which is why the limit never showed. The i440fx vz7.16.0 row
> uses all three (hw_compat_vz_9_1, hw_compat_vz_7_16,
> pc_vz_7_16_compat), and the next commit adds pc_vz_9_2_compat to it.
> With a fourth argument COUNT_ARGS returns that argument instead of a
> count, and the build fails on an undefined VZ_COMPATS_EXPAND_<name>.
> 
> [...]

Reviewed-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

-- 
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

Re: [PATCH v2 hci-8.0/hci-8.1 2/6] i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0 #PSBM-149402

[Andrey Drobyshev]

> Intel microcode updates for TAA disable TSX, and a host may also boot
> with tsx=off. KVM then stops offering hle and rtm, QEMU filters them,
> and a guest started with TSX can no longer be migrated, restored or
> reverted to a snapshot on that host: libvirt rejects the filtered
> features (VSTOR-75689, VSTOR-105458). The guest read its CPUID at
> boot, so the bits have to stay until it is restarted.
> 
> Add x-tsx-compat: hle and rtm requested by an Intel CPU model or on
> the command line are then not filtered, and KVM gets them in the guest
> CPUID, ignoring bits it does not support. This also covers Haswell
> parts with the TSX erratum, where QEMU drops the bits itself and the
> erratum microcode disables TSX. With TSX disabled by microcode XBEGIN
> aborts and HLE prefixes are ignored, so a guest that keeps using TSX
> falls back to its lock path. Where TSX_CTRL disables TSX instead,
> XBEGIN raises #UD, as it does with the libvirt relaxation this
> replaces.
> 
> As a machine type property it also applies when such a guest is booted
> afresh: it gets the CPUID it had on the older node, not a filtered one.
> Limiting it to -incoming would make the CPUID depend on how the process
> was started, and a cold boot with libvirt check='full' would fail on a
> host without TSX. A guest that migrated in already runs with the bits,
> so the cold boot adds no new failure mode. The kept bits are not
> reported as filtered, so check and enforce stay silent for them.
> 
> pc_vz_9_2_compat turns it on for vz9.2.0 and every older vz machine
> type. Release 7.x ships up to vz9.1.0, and vz9.2.0 is the last type
> based on a RHEL 9 machine type, before the QEMU 10 based vz10.x types.
> vz10.x types and -cpu host expansion stay strict.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 76289b86c28..25b17866103 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -548,6 +548,11 @@ GlobalProperty pc_vz_compat[] = {
>  };
>  const size_t pc_vz_compat_len = G_N_ELEMENTS(pc_vz_compat);
>  
> +GlobalProperty pc_vz_9_2_compat[] = {
> +    { TYPE_X86_CPU, "x-tsx-compat", "on" },
> +};
> +const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
> +
>  GlobalProperty pc_vz_7_16_compat[] = {
>      { TYPE_X86_CPU, "kvm-pv-ipi", "off" },
>      { TYPE_X86_CPU, "kvm-pv-tlb-flush", "off" },
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 1a50c2a645c..5be7c2ab967 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -1060,7 +1060,8 @@ DEFINE_I440FX_RHEL_MACHINE(7, 2, 0);
>      X(10, 0, 0, MT_VER_SYM(10, 0, 0), false)                                \
>      X(7, 16, 0, MT_VER_SYM(7, 6, 0),  false, hw_compat_vz_9_1,              \
>                                               hw_compat_vz_7_16,             \
> -                                             pc_vz_7_16_compat)             \
> +                                             pc_vz_7_16_compat,             \
> +                                             pc_vz_9_2_compat)              \

Small nit: keep compats in order, i.e. newest 9.2 first.  Just for
readability.

Otherwise LGTM.
Acked-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

-- 
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

Re: [PATCH v2 hci-8.0/hci-8.1 3/6] i386: keep spec-ctrl for AMD guests on vz machine types up to vz9.2.0 #VSTOR-151770

[Andrey Drobyshev]

> Since kernel commit de572491a975 ("KVM: x86: AMD's IBPB is not
> equivalent to Intel's IBPB") KVM offers spec-ctrl on AMD hosts only
> with IBPB_RET, which Zen 1-3 lack. A guest started under an older
> kernel has spec-ctrl in its CPUID, and QEMU filters it on the new
> host, so migration, restore and snapshot revert fail (VSTOR-151770).
> 
> Add x-spec-ctrl-compat and turn it on in pc_vz_9_2_compat: an AMD
> guest keeps a requested spec-ctrl when the host still provides
> amd-ibpb and one of amd-ibrs, amd-stibp and amd-ssbd. KVM then keeps
> MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD available to the guest
> through those bits (kernel commits 39485ed95d6b, 841c2be09fe4).
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 25b17866103..95ff2e7860e 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -550,6 +550,7 @@ const size_t pc_vz_compat_len = G_N_ELEMENTS(pc_vz_compat);
>  
>  GlobalProperty pc_vz_9_2_compat[] = {
>      { TYPE_X86_CPU, "x-tsx-compat", "on" },
> +    { TYPE_X86_CPU, "x-spec-ctrl-compat", "on" },
>  };
>  const size_t pc_vz_9_2_compat_len = G_N_ELEMENTS(pc_vz_9_2_compat);
>  
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 5ff5644dee9..872c00fc983 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -9116,6 +9116,19 @@ static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w)
>              kept = CPUID_7_0_EBX_HLE | CPUID_7_0_EBX_RTM;
>          }
>          break;
> +    case FEAT_7_0_EDX:
> +        if (cpu->spec_ctrl_compat && IS_AMD_CPU(env)) {
> +            uint32_t ebx = kvm_arch_get_supported_cpuid(kvm_state, 0x80000008,
> +                                                        0, R_EBX);
> +
> +            if ((ebx & CPUID_8000_0008_EBX_IBPB) &&
> +                (ebx & (CPUID_8000_0008_EBX_IBRS |
> +                        CPUID_8000_0008_EBX_STIBP |
> +                        CPUID_8000_0008_EBX_AMD_SSBD))) {
> +                kept = CPUID_7_0_EDX_SPEC_CTRL;
> +            }
> +        }
> +        break;

Failure case. -cpu EPYC-IBPB,spec-ctrl=on on an old node: KVM offered
SPEC_CTRL there, so the guest booted with it and used the MSR freely.
Move it to a Zen 1 to 3 node on 6.12. The host still has amd-ibpb plus
amd-ssbd, so the guard keeps spec-ctrl and libvirt is happy. But
EPYC-IBPB carries only ibpb in leaf 0x80000008 EBX, no stibp, ibrs or
ssbd.  Every guest wrmsr IA32_SPEC_CTRL now returns 1 from svm_set_msr and
the guest takes #GP where it used to succeed.  Linux logs "unchecked MSR
access error" once per CPU at AP bring-up and on any later STIBP or SSBD
toggle. A host-model or host-passthrough guest is not affected, since it
always carries the host's AMD bits.

Proposed fix: require the same bits in the guest's requested features, not
only in the host's:

    uint64_t guest = env->features[FEAT_8000_0008_EBX];
    uint32_t host = kvm_arch_get_supported_cpuid(kvm_state, 0x80000008,
                                                 0, R_EBX);
    uint64_t msrs = guest & host;

    if ((msrs & CPUID_8000_0008_EBX_IBPB) &&
        (msrs & (CPUID_8000_0008_EBX_IBRS |
                 CPUID_8000_0008_EBX_STIBP |
                 CPUID_8000_0008_EBX_AMD_SSBD))) {
        kept = CPUID_7_0_EDX_SPEC_CTRL;
    }

-- 
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

Re: [PATCH v2 hci-8.0/hci-8.1 4/6] i386: keep bus-lock-detect for AMD guests on vz machine types up to vz9.2.0 #VSTOR-152291

[Andrey Drobyshev]

On Thu, 29 Oct 2026 12:34:34 +0100, Denis V. Lunev <den@openvz.org> wrote:
> Since kernel commit 54950bfe2b69 KVM on AMD no longer offers
> bus-lock-detect. A Zen 5 guest started under an older kernel has it in
> its CPUID, and QEMU filters it on the new host, so migration, restore
> and snapshot revert fail (VSTOR-152291).
> 
> Add x-bus-lock-detect-compat and turn it on in pc_vz_9_2_compat: an
> AMD guest keeps a requested bus-lock-detect. The guest loses nothing
> it had: bus lock detection did not work under KVM on AMD before kernel
> commit 62ad461079e7, DR6 bit 11 stays fixed, and a Linux 6.13 or newer
> guest only logs one "unchecked MSR access" warning when it brings a
> vCPU online.
> 
> [...]

Acked-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

-- 
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

Re: [PATCH v2 hci-8.0/hci-8.1 5/6] i386: keep v-vmsave-vmload for nested AMD guests on vz types up to vz9.2.0 #VSTOR-152264

[Andrey Drobyshev]

On Thu, 29 Oct 2026 12:34:35 +0100, Denis V. Lunev <den@openvz.org> wrote:
> On Zen 4 client parts (family 19h models 0x18-0x1f and 0x60-0x7f) the
> 6.12 kernel clears virtualized VMSAVE/VMLOAD in init_amd_zen4(), which
> some BIOSes trigger on reboot, and KVM stops offering v-vmsave-vmload.
> A nested guest (svm=on) started before has it in its CPUID, and QEMU
> filters it on such a host, so migration, restore and snapshot revert
> fail.
> 
> [...]

Acked-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

-- 
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

Re: [PATCH v2 hci-8.0/hci-8.1 6/6] i386: keep SVM leaf features without svm on vz types up to vz9.2.0 #PSBM-144630

[Andrey Drobyshev]

On Thu, 29 Oct 2026 12:34:36 +0100, Denis V. Lunev <den@openvz.org> wrote:
> Since commit 730319aef0f ("i386: Mask SVM features if nested SVM is
> disabled", QEMU 5.1) the features of CPUID leaf 0x8000000a are dropped
> when svm is off. QEMU 2.12 on Vz7 kept them, and a Vz7 host-model
> guest runs with svm=off,npt=on,nrip-save=on. Moving it to a newer QEMU
> fails in libvirt (PSBM-144630):
> 
>   guest CPU doesn't match specification: missing features: npt,nrip-save
> 
> [...]

Acked-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>

-- 
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>