From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a187a30bcd-9b498923-9320-45fc-9049-596cdebb62be-000000@eu-central-1.amazonses.com> Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11023126.outbound.protection.outlook.com [52.101.72.126]) by lore.virtuozzo.com (Postfix) with ESMTPS id A35A980E7E for ; Thu, 29 Oct 2026 12:29:36 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ac/nJS0/QRrZmIdDjcu+XaeiVZ/d+gYPRbMHZVWCkpicZtq7odvsoorMXTwQqpq+80PoTohy8rrCZCCQUEXkYui+8FQSo7sDVQBPLx4+Vb7CDybPV3YvCz2poYyZbizEmzYUPwJGOls16xR7d6emj77uiBO/Ox4kNbbq9NCwn/4M+ZW96tR0Gpo30kM5hJSMCtPDcECqiKWeqM9JjnT4mjvaObT+Wjw+F9SdF1mYbWBtrsHZ+wMv0QegheIh7zHvYR9p7TQyWcCeDeiPnYfJNewJZvyYNNIzTucqA7VYgwzAX74uBGMjHqy0yV8URham1/eV4ihD3AaInzSmUbQv4Q== 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=QwVGWeSHgERzhnhKsAq7Ct8kK+j2YEzx8HHHsQl0GuI=; b=Tftx/Bz0estkHNlB1G6BodmlEflSAQ14YnK7se0MqsASQ/GfjjcjwoWLlFP0zeAtmAuABl5TibSKA4AbKstoydBFFK/R28Cgqf30CphU1sKWMclo0Br42Nbpee98+1Tm4add5X1ILmisKjX3VuaPcYwDlhLJkhwvo5fN5zfG5GcA9PHZRbDHY4gViRuwIn8jAf78p/RqoH6ixtSgX/2/XZY31HjuDVdi9MQpNrOcy+6kVDMpbk5j9oAh6zn/pxQTAf4leCeL5zWvW4OfshY2NbnQha29ITFeVCAoxjoaHVUI0e6lsZh1hsngmE7JtzQnqfWH7nN53dhl1bEbQDixjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.6) 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=QwVGWeSHgERzhnhKsAq7Ct8kK+j2YEzx8HHHsQl0GuI=; b=ZjYpwLIKYcauXgs+HbOg5DVZ9stR+STKEr58NVxQ6hnb+6fAoR01vxAbqgzSNjo7gLqGXlESIYJ15dlSGhbQKVgjV+BzaARR5JKfF3L1olTKG2NQqUIwBZ5RQq4JccR6s2B0bGMJjZ3Yh19n2IyJssAxha4DlL6edMr9CIginow= Received: from AM0P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::13) by BR0PR08MB637335.eurprd08.prod.outlook.com (2603:10a6:2c8:64::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.8; Thu, 29 Oct 2026 12:29:32 +0000 Received: from AM2PEPF00070CF2.eurprd02.prod.outlook.com (2603:10a6:208:190:cafe::17) by AM0P190CA0003.outlook.office365.com (2603:10a6:208:190::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Thu, 29 Oct 2026 12:29:32 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.6) 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.6 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.6; helo=b224-6.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-6.smtp-out.eu-central-1.amazonses.com (69.169.224.6) by AM2PEPF00070CF2.mail.protection.outlook.com (10.167.242.4) 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 12:29:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793276972; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=7KyYX1LkSxEtacSRuLiOLXUKVyBqDGg0g7TKYkEeMkQ=; b=QoVVknKegxWGaIqN+iGWpyfBKZecFCTP53ciDIGzcKQLRiRVB9hXq1r8qRFF8rk5 unaw8p6XfXdcpxY63E9tt3KWhJJqZ/wxaVEBR4V6tBg6eXxe6xYbdUSxYA7HgvZ4F4T BZlNHr9WLN6vh7pM89Fi9JXVjVE45/JXzy9eQ4oIBEAPEWfnx5zJQ8VZiUFcwx2Up6l 4vQmwtlWTGovqq+DNWMOJbmVXGuJjF0lUJOZXOdNdTpDYJuC06dxXVs8MKCIkz17ZMK flm9DpzFN0AecMfHP0R6ySGwqG2oQL2syxPAydmVwPbD4o0TeAwrD8Rd+3vZNWdG1wT S51PgQQRHA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793276972; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=7KyYX1LkSxEtacSRuLiOLXUKVyBqDGg0g7TKYkEeMkQ=; b=L9BQV/ksDskKDRkzOGaZEHVSZao0WWsJjmSMVgOCzcz47etTokuZ3wWkuU0L9pS0 4fYOGJ2SWihPDBU8DQ4N00X/hWDXQ4n9mQ5DVvefofrGC9bu2e4zF4h55IkHgdOizn7 LomAR1pd8tY0YngV0zismNZ+rWSSUHMY9mT9Q++o= Message-ID: <010701a187a30bcd-9b498923-9320-45fc-9049-596cdebb62be-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH v3 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: "Denis V. Lunev" , andrey.zhadchenko@virtuozzo.com Cc: svt-core@virtuozzo.com, den@openvz.org In-Reply-To: <20261029122527.365104-3-den@openvz.org> References: <20261029122527.365104-1-den@openvz.org> <20261029122527.365104-3-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2026 12:29:31 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.29-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM2PEPF00070CF2:EE_|BR0PR08MB637335:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9c365a14-3d74-4418-2345-08df35b848f3 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|48200799018|376014|61400799027|9140799003|32142699015|261028144727099003|261026121527099003|5023799004|261026140227099003|5063699009|56012099006|4143699003|261009223027099003|261021121427099003|261026135527099003|261022105027099003|261021123027099003|10067099003|18002099003|55112099003|16102099003|22082099003|5113699003|4113699003; X-Microsoft-Antispam-Message-Info: n5wiAMQ3qKHwSvoZNgYVyvQG4+fUyoTSJj78g7KRshTvFH0OQ0xnnd61/McCLY5QrR6C+f4+Toe8wdl3IwcaLS3ejdm6Go3G0MmfkZc6wXhP7Dabr2Izwtt89/gTXgkPL5wnU8rMrCHHR6Y9EveOc75JNlK6mj3UKLmPkATjp+bOxw46zubTJu4YBwxV57i55zgZySKUjOk4uxFQXNhyV/JUYHYIwOW+c2qAdmHLT6Wxchl618QpMFEKVn+acev5SjjfClelwVU2P8vKRtZFXpGZMsxodv2crn/ZEDM+jD9K1hmQmheSSNhzZ+rGy1iXJR47MYX3ZCivZoWg8VWF78wGOpElJuVMiMhYSOIzCkvAVzpMNeXisva8C8pR5d/k/iVwTuwPLzGYdxHBatHDr7Iwjz05+4tl01c7YS4rCn+N43ajNjibTJVrvc02DqMjWb7Txqr5WAN+K5ZMtWqKED5dW+H3RYiQdh6wC0jiNNm3Ty/EY5X2oxKOgRUz5ingPHHoce9RLw1N7vfYP5YgxHdWpNiMfCG6kYFc4gs2HxO9FbyGuTk0jisrDc7aFP1h45iOyI3vin30ILEqXhhsRIwgnikUakC0Ju95R1I6RpwEGTaH/9dbqghzTKa6Sm5uHv56QQyqbWQZOO9Ax/T8H1CBSP82qOFjUrRhVm4EbHKq/wt3Hah7mJ+KEsuyl8lIosUPi/h0DnrJc1tl/NkkoUvgGUnjM4Cg7yboTcbKtCzioWhMaYaW64AlvxbnsP9HN0P70bGRGDu+Lm3fDYgH2xHkG+rhPr8u2adL83WeAveM+NLluEEnrtWGAVmVPWLOePGbim/Bk951xTEdZmf29Ne20ZDQprD4cS3tNBsaBskin3atpaC08y15hlSK0oDsxpZVoVIp+uiAxVb6y4XOSw== X-Forefront-Antispam-Report: CIP:69.169.224.6;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-6.smtp-out.eu-central-1.amazonses.com;PTR:b224-6.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(48200799018)(376014)(61400799027)(9140799003)(32142699015)(261028144727099003)(261026121527099003)(5023799004)(261026140227099003)(5063699009)(56012099006)(4143699003)(261009223027099003)(261021121427099003)(261026135527099003)(261022105027099003)(261021123027099003)(10067099003)(18002099003)(55112099003)(16102099003)(22082099003)(5113699003)(4113699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: n/3mZy24mMwm/S+dvtnReWmn2y86jthG7V+fWoe9+sbXxDmXR5g0Dd/5Nc5RynlpZzxKwAu8pjykug3dIrrjjhg374v2RdBvku6YYHotoAHsKI8PS67grDoXUD+EJ6gjotkGuUTE5pOun0+WrHEgTuZQuptcqMIZNNCAqrTuqED5xhrAcjICnZwGpYUWAMTDVaHXUpvfa/LhQfyAMQH4DSnYGMaKdkVElcyuG05J+yDD1ozdm6i/yU0FjXee+CLXwyHKfIXKs+MR4aVd8SRfXZUC2Nnm13ngYIWwf5ac3GnuM/nDwz9R3yNzz+e6capC0lW8UPV99UIUHcXlux4FcS8o4t1r0NIZpvlH8U5VIi5XnmergdEyrD7ALmLlBme625mekSbGUiarOAGiuvOY0Ko68IrJxE6OSdDfRSF1wlJYXAxvCxu7WUb0jU2xuQ0a X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 12:29:32.3443 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9c365a14-3d74-4418-2345-08df35b848f3 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF00070CF2.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: BR0PR08MB637335 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] i386: x-tsx-compat keeps HLE/RTM without checking host TSX suppo= rt -- commit 958d84e4025a51fe913636203f3656b7b19673c8 Author: Denis V. Lunev i386: keep hle and rtm on Virtuozzo machine types up to vz9.2.0 #PSBM-149402 This patch adds an x-tsx-compat CPU property. When it is set, HLE and RTM requested by an Intel CPU model are not filtered out under KVM. The property is turned on by pc_vz_9_2_compat for vz9.2.0 and all older vz machine types. The goal is that a guest started with TSX can still be migrated, restored or reverted on a host where microcode or tsx=3Doff has disabled TSX. > 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 property, it is also on for a cold boot of every vz type up to vz9.2.0, not only for incoming migration. Can a cold-booted guest end up with HLE and RTM in its CPUID on a host that has no TSX silicon, for example an AMD host running an Intel-named CPU model, or an Intel part that never had TSX? > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c [ ... ] > +/* 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 =3D &cpu->env; > + uint64_t kept =3D 0; > + > + if (!kvm_enabled()) { > + return 0; > + } > + > + 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 guard in x86_cpu_compat_kept_features() checks only kvm_enabled(), cpu->tsx_compat and IS_INTEL_CPU(env). IS_INTEL_CPU(env) tests the vendor of the guest CPU model, not of the host. Nothing here checks whether the host implements TSX, as opposed to having it disabled by microcode through TSX_CTRL or RTM_ALWAYS_ABORT. The commit message justifies the bypass only for the second case, where XBEGIN aborts. On silicon without TSX, XBEGIN raises #UD instead of aborting. Could a guest that trusts CPUID and uses RTM (glibc lock elision, libitm) then take an invalid-opcode fault? Would it make sense to restrict the kept bits to hosts where TSX exists but is disabled? This also bypasses the existing safeguard in kvm_arch_get_supported_cpuid(): target/i386/kvm/kvm.c:kvm_arch_get_supported_cpuid() { ... if (host_tsx_broken()) { ret &=3D ~(CPUID_7_0_EBX_RTM | CPUID_7_0_EBX_HLE); } ... } The commit message says this is intended for Haswell parts with the erratum. Is it also intended for hosts with no TSX at all? [ ... ] > @@ -9126,7 +9149,8 @@ static bool x86_cpu_filter_features(X86CPU *cpu, bo= ol verbose) > uint64_t host_feat =3D > x86_cpu_get_supported_feature_word(NULL, w); > uint64_t requested_features =3D env->features[w]; > - uint64_t unavailable_features =3D requested_features & ~host_fea= t; > + uint64_t unavailable_features =3D requested_features & ~host_fea= t & > + ~x86_cpu_compat_kept_features(cpu, w); > mark_unavailable_features(cpu, w, unavailable_features, prefix); [Severity: Medium] In x86_cpu_filter_features(), the kept bits are removed from unavailable_features before mark_unavailable_features() is called. The bits therefore stay in env->features and go into the guest CPUID. They are also never added to cpu->filtered_features, so the check and enforce warnings and errors stay silent for them. Is it intended that enforce can no longer reject HLE or RTM on a host that lacks TSX entirely? I did not trace the KVM_SET_CPUID2 path in kvm_arch_init_vcpu(). The commit message says KVM ignores unsupported bits, but the kernel does not validate userspace-supplied guest CPUID against host capability. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026102912252= 7.365104-1-den@openvz.org?part=3D2