All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: "Denis V. Lunev" <den@openvz.org>, andrey.zhadchenko@virtuozzo.com
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.0/hci-8.1 2/6] i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0 #PSBM-149402
Date: Thu, 29 Oct 2026 10:02:53 +0000	[thread overview]
Message-ID: <010701a1871cc8df-57fe83de-cc5d-4a67-b707-852fa5e7876d-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261029095645.4173762-3-den@openvz.org>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] i386: x-tsx-compat bypasses host_tsx_broken() HLE/RTM filter on erratum CPUs
- [Medium] i386: x-tsx-compat is per machine type, so fresh guests also get HLE/RTM unfiltered
--

commit e10a786995ad2ad41a1d6c5331e18ca149f90107
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 set, HLE and RTM requested by an Intel CPU model, or on the command line, are not filtered out under KVM. The pc_vz_9_2_compat global properties turn the property on for vz9.2.0 and older vz machine types.

> 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]
This property is applied to every CPU on the affected machine types. That includes freshly booted guests, not only guests that are migrated, restored or reverted to a snapshot.

On a host with TSX disabled, a fresh guest on a vz9.2.0 or older machine type gets HLE and RTM in its CPUID. This happens when it uses an Intel CPU model, or hle/rtm=on.

If TSX_CTRL disables TSX on that host, XBEGIN raises #UD. A guest that probes CPUID and then uses RTM could fail. The commit message acknowledges this #UD behaviour.

Is there a way to limit the compat behaviour to incoming migration or restore? Alternatively, could the commit message explain why applying it to fresh boots is acceptable?

The commit message says vz9.2.0 and older are "the only ones used by guests started before release 8.0". Nothing in the repository shows this. Could this claim be backed up?

[ ... ]

> 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)
> +{

[ ... ]

> +    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]
Can this bypass the host_tsx_broken() filter in kvm_arch_get_supported_cpuid()?

That filter clears RTM and HLE on Intel family 6 hosts that have the TSX erratum. Those are model 63 with stepping below 4, and models 60, 69 and 70:

target/i386/kvm/kvm.c:kvm_arch_get_supported_cpuid() {
    ...
        if (host_tsx_broken()) {
            ret &= ~(CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_HLE);
        }
    ...
}

On such a host, with tsx_compat set and an Intel CPU model that has hle/rtm, x86_cpu_compat_kept_features() returns HLE and RTM unconditionally. They are then removed from the unavailable set in x86_cpu_filter_features(), so they stay in env->features[FEAT_7_0_EBX].

kvm_arch_init_vcpu() builds the CPUID entries from cpu_x86_cpuid() and passes them to KVM_SET_CPUID2. It does not mask them against the KVM-supported set again, so the kept bits appear to reach the guest. The guest would then see TSX on silicon where TSX is known to misbehave.

The commit message only covers TAA microcode and tsx=off. Should the kept bits be limited to cases where host_tsx_broken() is false, or should keeping them on erratum parts be explicitly justified?

> @@ -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);

[Severity: Medium]
The kept bits are removed from unavailable_features before mark_unavailable_features() is called. They therefore never reach filtered_features.

As a result, the verbose warnings and the enforce check stay silent for HLE and RTM. This applies to fresh boots as well as migrations.

x86_cpu_filter_features() is also called with verbose=false from the CPU model and definition reporting path. Could that path report a model as runnable on a host without TSX?

[ ... ]

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

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

  reply	other threads:[~2026-10-29 10:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  9:56 [Devel] [PATCH 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
2026-10-29  9:56 ` [Devel] [PATCH 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
2026-10-29 10:00   ` no-reply
2026-10-29  9:56 ` [Devel] [PATCH 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
2026-10-29 10:02   ` no-reply [this message]
2026-10-29  9:56 ` [Devel] [PATCH 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
2026-10-29 10:02   ` no-reply
2026-10-29  9:56 ` [Devel] [PATCH 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
2026-10-29 10:03   ` no-reply
2026-10-29  9:56 ` [Devel] [PATCH 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
2026-10-29 10:03   ` no-reply
2026-10-29  9:56 ` [Devel] [PATCH 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
2026-10-29 10:07   ` no-reply

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=010701a1871cc8df-57fe83de-cc5d-4a67-b707-852fa5e7876d-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=andrey.zhadchenko@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=devel@openvz.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.