From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a18774cf0a-bfb67a8e-8e72-416d-90c0-aea0e3ba023b-000000@eu-central-1.amazonses.com> Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazon11021101.outbound.protection.outlook.com [40.107.130.101]) by lore.virtuozzo.com (Postfix) with ESMTPS id 5CCE380F81 for ; Thu, 29 Oct 2026 11:39:06 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AhiXh6Fw8OHGr29BdbItlE3N24o/f7OoLMzYyJT9/1bJLPG9/QfJa6q0nIvUymDjPA7LOE1YFktbEHzjhPnF6xmf3V49KtNbCKDOLPowzTMvX4MCj+0a3C1x2IUBE5hpeJTaRziTnuhD/Cvy1fC2WBPmo56W8Tj6q/R7IKqpPXPkZ2YYwfOMpwVRYvS4ligfCmze+Q/Ie0yl75gcjiYMx4ZTmsv3eHam+tXUjklFlnyjpFVrPMdRJkm6skIKsChNWFeYE+dL5ItqRrAbK6/WAN4chCGcwk6BpDtbrZ5rY66CeUD4UxRvMS1BjX3S/dFYa/z4wGwG0hOfOcrIkOYRjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QLafSz8/+rBH80N0WfIFmjrFOSZzBJzRX88woxPDQn8=; b=Ms0ppHmzeufXypmrfPUMjq78KmUbTwqq9lEzsxo0UyKDwLkffSpw9dfFyu3no9rltnzSdQMBbnZszu8XseYJJwj0IBmrCGi9M9OJcHy4zmKVg9n/mTAXVg1pgHpscxl61ptTGDOCqyyFXBYgebYIU0MBOu17gJTL1gr3ikrqgB0UCLXdT0qNM+sdziUrY3etO9Px8V5Sg8nXWaft9NMuFPwNZXBfq2/MFf+uxFGQ6I31jW7NcEOg+Ki/kVeFEpAahjaUkE9ZNmbAti+bXbYs1bigqm00i8jWSuxcMJ6tTlBzr2mYYI1Q7CHhJlRhrWhHeuLYu+5Bb7rIS0ZJ7kcpDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.5) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QLafSz8/+rBH80N0WfIFmjrFOSZzBJzRX88woxPDQn8=; b=GM6LQ0m1BDfx79k4fc4g0zAEmB5cZSg8qgIBOBTS7o3X5bJ/SG8DXWeRyr9saz3maZ7jNI1aHkzZkOt1eMTFoNhtQuO52yMLxkh7KmqmG72U2x2FzAhVjM8UchBfweP5xPBwtHM59vKonDHm2/3aLRu7EpdfenkuHnHsUfexwmk= Received: from PAZP264CA0223.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:238::9) by AM0PR08MB5409.eurprd08.prod.outlook.com (2603:10a6:208:183::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Thu, 29 Oct 2026 11:39:02 +0000 Received: from MAD0EPF000008BE.eurprd04.prod.outlook.com (2603:10a6:102:238:cafe::a) by PAZP264CA0223.outlook.office365.com (2603:10a6:102:238::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.7 via Frontend Transport; Thu, 29 Oct 2026 11:39:02 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.5) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.5 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.5; helo=b224-5.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-5.smtp-out.eu-central-1.amazonses.com (69.169.224.5) by MAD0EPF000008BE.mail.protection.outlook.com (10.167.241.165) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Thu, 29 Oct 2026 11:39:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793273941; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=VKlQaUanzuXhVRmS2+udsWMSvHWvZAOn03JQqp3MTNE=; b=SuJ/sdBTOnE/61H9ubuHzgLSOn9E1mPE3JuxTPx3PWtetuEpgV1n3Vj6z5yyeBU7 svBmz4Enri7PXYMjcO/Ej6LPbUGkk0eBylOWoHy/w/Xa+jQfUcwSfujn9dk5iMN/7Cq ckon7E4igJ6gzyfMuttLwws5NK1+ddq2DM2cZsmvTrTPM4KNh1C14C3zVZsWmfdm+Nc 2YkVaW6dcjPdOu6KJyJ0gl1Ies5b3lVXEHLcr/lbI/9eyXfOn3QiLqGqfVW1MpAD4MW WEdMLZ7gYECyUF4djcRKBOmOibyYffy3GVP1uLm9sDa39eJ+7LZFtVk08AvW5y94/zU QaABwwITlQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793273941; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=VKlQaUanzuXhVRmS2+udsWMSvHWvZAOn03JQqp3MTNE=; b=X+DK9IpGnFU4ebg0UgsKbm/GPZDqQqKJ40Ap74q4sKvvFuZlRvAqvxWOAUOhs445 vMKDAX8gqL65i4CEfS6v+hnZUHUiopoO2oSQD15QkeFzaa/Zoi23dYinMVGonOBd4jH clj9A3rlz1QR7zPVThtSALYtog/kpVmIinFt2Trs= Message-ID: <010701a18774cf0a-bfb67a8e-8e72-416d-90c0-aea0e3ba023b-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: 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 To: andrey.zhadchenko@virtuozzo.com, "Denis V. Lunev" Cc: khorenko@virtuozzo.com, den@openvz.org, svt-core@virtuozzo.com In-Reply-To: <20261029113436.93521-3-den@openvz.org> References: <20261029113436.93521-1-den@openvz.org> <20261029113436.93521-3-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2026 11:39:01 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.29-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MAD0EPF000008BE:EE_|AM0PR08MB5409:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9ce09c16-3428-401d-d26d-08df35b13af8 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|376014|48200799018|61400799027|9140799003|32142699015|260925021311599003|260925022911599003|260925021911599003|5023799004|4143699003|56012099006|5063699009|261009223027099003|261026135527099003|261026121527099003|261026140227099003|261028144727099003|261022105027099003|261021121427099003|261021123027099003|10067099003|55112099003|16102099003|22082099003|18002099003|5113699003|4113699003|13003099007; X-Microsoft-Antispam-Message-Info: 8Ms7A04i+V7Y2f2RJ9y0/hNwq9NvGyY8j9kDFv6ZHzwAMrGRWv+7C6wP+86jT1RVNyxD6wiStzofasDOEUK9+VgM+HulfTEc88dZc/H6w0Rry4n7D1CSLkvvTI0odt1X9kokDFsodMpPY2G/N9cgmZEgVA26y1EaGGcda81T6YEYsAJJXsLnPFivjhCqP+7YBw+ec4bNbYSGkUjmtvVCoDJUgCcP35RGoAy9DQD+jIwRtbEBPqh1fcdCMKulW/SZaTTU1E/CjmEa1R+wjXFCcN0sHXofeeOCm6q3LZYz+WBlS9awEtx5WmYEnyT8ByB41NjqxkCyK2prPLhWAaeuJUxoH/g6tir9DEP2tTQpU3x1HknwzqMW9zhzbO6LEpbUgF42Uq7WT57QSIOT8CIEDQRhy93VBPSkSQnhD05m1yZ51ddATNn4eigkuM+uWosVGknQX3AuT2SDTjxyV31/Ppr2ljPtE56S0OEAd0IbdP7TAQDkD00ZTutshR5WzgAQwKXs3M6BjAdMvAX8N4yhkn85ezONN+5jyW12USS8pAyf+S7SQ2baiHWP7oPV8eGgycnw+9fm0GSXuY4FXtNKcdExb68G+P/5M/mFCflu/d9v5+zolNPHTfEFbRyBr597JYKaL/NZmGMcb1tZecMaiLq4/QBCFiGx+2yamBfA7DW0VnyChea1ZK88Fun5W32Dew945PDYIsLutVIaujZe+TiP6Syd2GafZnNA4zYagjmicIw4pVS27bsFLK8RR/akwAYVwfZTA1HbpSpXKBputUe2q+1OBY/nyBLE0ooxfxAMxNR6qe483pAaokUr//VedqawSYtHV3+UXU9qqxlacYPLd8CzuVg5weADwT1Gb0IFxUO+/M+j1N23ts7+J3XYaJKZQjcsmHhnDfivIKWS5A== X-Forefront-Antispam-Report: CIP:69.169.224.5;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-5.smtp-out.eu-central-1.amazonses.com;PTR:b224-5.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(376014)(48200799018)(61400799027)(9140799003)(32142699015)(260925021311599003)(260925022911599003)(260925021911599003)(5023799004)(4143699003)(56012099006)(5063699009)(261009223027099003)(261026135527099003)(261026121527099003)(261026140227099003)(261028144727099003)(261022105027099003)(261021121427099003)(261021123027099003)(10067099003)(55112099003)(16102099003)(22082099003)(18002099003)(5113699003)(4113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 3wKyE02TfOxRNiRJxvLjNNtKcUdtsM8XcVOeCb7wxzxn20F1FXxngIHqVdeMrfwjypJ+hY7I2clY8rj+MPYttZwB8Ou9mFYEcj9nQYlTq5iY/5xcchqRwo4kgMjpQiKD2wFZiJ8U3kcYQUFdoscIxoieWsgh3ruMb+fkCABb5EDMO7MAsZ4SsEFeoQJFdRuOk7u8VFv6+laM9GqegVAglTWFqwp7NTz2uB3t/DqQIZ01yEdwaNWyJKUrrXT9z/IsTKVg3SFGRZ59tekwORLYoF2kSnNkWIDqBDW9XGLa2sKHgTdadL4taoilHy25S2uLIBi1OTj0ZxQAAbdMbyLhloStXQJTo3oM72HkQbECMXAe0LOe4RpsQI5gGzVtm1cJ8OlNYAendxsxRxiDxqdZbbQAYNuhn/Lvw5EKx3WtFYLE4id4J8FI9Yv6KxCx1lBx X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 11:39:02.2897 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9ce09c16-3428-401d-d26d-08df35b13af8 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008BE.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5409 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 hos= t TSX is off - [Low] i386: x-tsx-compat keeps HLE/RTM on Haswell hosts without checking = microcode -- commit dbdfc9450553c67e1ff2b80314cb5e7632457006 Author: Denis V. Lunev 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[] =3D { > + { TYPE_X86_CPU, "x-tsx-compat", "on" }, > +}; > +const size_t pc_vz_9_2_compat_len =3D 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=3Doff 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 =3D 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. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026102911343= 6.93521-1-den@openvz.org?part=3D2