From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11023104.outbound.protection.outlook.com [52.101.72.104]) by lore.virtuozzo.com (Postfix) with ESMTPS id 34DB08017D for ; Thu, 29 Oct 2026 13:48:08 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JhhY4nVZpxI49kz393op8xmRvRQ73NjA3JOF/3yEghGbP2p4kscw7Qqr/9sn0+J8t3erCJt7U1y3zzEL8rRFifklewLoLE1rGVMbVyM72m5OSTMFpEJAZn2YLJTitPwFmyWesO7Vj/dpwHKFL4DMm0LhgszRWnCXR/aIZzcGsug6Tea0T6ytjdnNqm6pY8fwgSHGzmTrFXaFKwPqRQSnwDgEQk01JNIcyCq+41t9npiQh2/v+SkjqOyv7U7IbQsdNmQ5IR+Numwp0YRSwaNt4k5gvSmhfDb1JZfw+KT+KIv2ula+EHrGtsFIdOOFEwS6jeqySZXoD3FWXBNYq+CRMA== 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=LKASGxfh1pXNexUiGxHPYYwJQ1anDC0SaWcJgx7Dkj8=; b=bEBAhXtF7v+M/4EsYFJi2wCPWhsdQbvYNFQO19/Ioy6eAtVqX++eZjxjfAf99AxV7YJJxaIaHZAaJt7Cmj8JiG7o5XQVX8Khwj1A+TBjmsTQZxHdpXCF9e7cmUBmfOB2oVNeN1Id5iwdWZMIdgz9DeCDYrhFB3O7Yfk+Rsxc+o3uX31FxnzwEzx276EeT33xV+W9ilEvrbZxzF2jpvg8uY0Nbkam00ZpqGK95Q0rqRJv9oGAb86Gmqf310LIsa7wARRE5Q6Mr6ApK0tFjDtEVoZ/J5gt8DcsqgFJW3ETgP2oSwi0MwN9IJHhRLtfS++O/hYO4V1W9MTj6QtBVK1bwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LKASGxfh1pXNexUiGxHPYYwJQ1anDC0SaWcJgx7Dkj8=; b=uRI94+RQVPctNJVJOtRRhqXnoYvo3dTDPU0W2rtyo/G78BnGWRD1NKC9e9FIccVUu6FbnGEAmqE1c9yCab9ro4V791efnoCfhBO+5ovVkNegiyNmnRYAy1YiCXO7fohz0A9pffqPgJDSTqk77sCjZ0tcKC1SjqUvTzgaAYlbD/vJCkxxBnBBGBzjwlzWOsBilBernpJTXR0E61gwMPJNWolywBBvgHa72xGbpfbdXHJnwWcYpNirawoceP2EbdzkYeMNJXFrBSRCRYtfy8ciyybNln+WyEdyU1+VF8WSiSfXMvI1T3op0N0ASdGElqZ+ixy8pJQoco1DnBHYnyqQJQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from DBBPR08MB10650.eurprd08.prod.outlook.com (2603:10a6:10:52d::7) by DU0PR08MB9370.eurprd08.prod.outlook.com (2603:10a6:10:420::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.20; Thu, 29 Oct 2026 13:47:59 +0000 Received: from DBBPR08MB10650.eurprd08.prod.outlook.com ([fe80::1b2a:832c:d136:a37c]) by DBBPR08MB10650.eurprd08.prod.outlook.com ([fe80::1b2a:832c:d136:a37c%3]) with mapi id 15.21.0569.007; Thu, 29 Oct 2026 13:47:59 +0000 Message-ID: Date: Thu, 29 Oct 2026 15:47:57 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 hci-8.0/hci-8.1 0/6] i386: keep CPU features of guests from older nodes on vz machine types #VSTOR-152264 From: Andrey Drobyshev To: "Denis V. Lunev" Cc: andrey.zhadchenko@virtuozzo.com, svt-core@virtuozzo.com References: <20261029122527.365104-1-den@openvz.org> <179328064793.774312.5097011755521614906.b4-review@b4> Content-Language: en-US In-Reply-To: <179328064793.774312.5097011755521614906.b4-review@b4> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: ZR2P278CA0013.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:50::17) To DBBPR08MB10650.eurprd08.prod.outlook.com (2603:10a6:10:52d::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DBBPR08MB10650:EE_|DU0PR08MB9370:EE_ X-MS-Office365-Filtering-Correlation-Id: ba0ba3f9-0847-4787-046a-08df35c33e18 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr 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|376014|366016|23010399003|1800799024|22082099003|6133799003|5113699003|261026135527099003|18002099003|261028144727099003|261026140227099003|56012099006|4143699003|10067099003|261009223027099003|261021121427099003|261022105027099003|261022075727099003|5023799004|261026121527099003|261021123027099003; X-Microsoft-Antispam-Message-Info: XrXbRZ4L1LwFeIP+t85sktyAZUBcQowYrgcNgE/RCXkzHnIX/OuHH9Lbu4JYtndqHr/myNqwmsXJrVKxYo39riIroOuJ/FjJxpTNCetEWsVBIKnPgSswfyG3yYy19mhCGy7i1zp7Mwy0emmvss5TT75g71K6Fmq02a7enUFEvITOZMb+CkbJHsynwqC5/6pxzEJtTFo/8eVb1qPvJKLmnK+2d+tG6pnGluYonALTmKYytxBZJwziAafVucGRtIalXMCRt1l8sUeikyu3eCwUsUV/EnEIPkU0SeUWXWOfnIJG7kEomS4zRzT91xLlBS9+743O/9RTcbvdp3xffDhc1IC/SHSw+TQ3qREWP+sDmiOoDxaZEXVM8su6yI9vm9fCifFVU9R7JykwYDJDqo/Q0ztfplCQ26WsIPyUcreRGBtLGamT6BnmViyX0Ys+FrQYIvtxOoOAsCf2NwaSzFWieIgG3EduYgSR0keaVqXQkMdg9ck+96DGZeoXpkhgW5vCgixZCbcMrX/ysP2D2PVXte27yjuoc62CNtnqKzQwl5ih5TsXv/SKFJ0kK5Xkanyngsui+NOur84zVpggDKRtZEuPhfmUc4NdDh+0R2yruMk/2EnWjXVyvMrBHmwCVN82 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBBPR08MB10650.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(22082099003)(6133799003)(5113699003)(261026135527099003)(18002099003)(261028144727099003)(261026140227099003)(56012099006)(4143699003)(10067099003)(261009223027099003)(261021121427099003)(261022105027099003)(261022075727099003)(5023799004)(261026121527099003)(261021123027099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aEMwdEZNeTVXWTRjbDZWVnl2a1hGNXUrbnBCT05tWnFWYU45WFRwWWtXaU1X?= =?utf-8?B?UFBUWmdFMDdlOGVvMUdNQkVQSTNyMkM2aFV4cm1WcmlCOUQ5N2huV0VQc0E0?= =?utf-8?B?NnF2aTUzUnJCakZYU05MYmxQK01oNmpBWnBvMlcwNUhZZzdrd1RXZVcyaTgw?= =?utf-8?B?RlJ5NmEzc2sxdlc0TXI0TzFnUVlMMWFHcVhESmZzV3hlbVZ6SFdoSnphTytt?= =?utf-8?B?U0hjNThEcUx5TEtBVHI4bkdMZnczblVxWXV6M3U2QWdHMFMzM0hRVU0zaGJm?= =?utf-8?B?UkRjYTh5UVpPbzNqNVFtVXpsMjRESjJXWXdoNTdYYk83QmRpeEpHRHdMbUt5?= =?utf-8?B?QlVPQlprVVFEWGllZUwwUFo2QWNDbEVGQ2Uvc0JjbDNHMG1xaDBNcmVOdi85?= =?utf-8?B?QXFyWE82YkR5WHM1ck12ZVBaUTA5TGxnMXc3dy9rZnhsTzZJM0hLQUo0NWIr?= =?utf-8?B?c1FkZi9PQVlxNUpxMDhWMWdOK3J6WG80cFVpZHQ1SEI4RkRXVldUaHViZjg1?= =?utf-8?B?ZG5BQUZpVUd2YVJiWlBsWGsxa3pNblhNRENWOHAxY3Rac3lKeTJDZHlQdy9M?= =?utf-8?B?NE9heXBmS2x5MkpmSVQwek0yWG02S2FPdDdoVTVzdmNnRllHTkRncXRPaUh6?= =?utf-8?B?OW9rRjNmQWxWTWRVRlo2elNtM1hTWnhpcEFNNzJETytWOTNLZ3VXc0MwQkZT?= =?utf-8?B?T0k5cWRqN3JmRTFaQVNGS2JVeXZVT3VLaUhsMElUemJzTnlxcXBvM1g1UWZu?= =?utf-8?B?bWJiaElSM3JqZmFxdDAzQWhJVmUrZVNQTGdadURsTlB5VkV5anJSaVpRR1FU?= =?utf-8?B?Rks1Q3VnWHN3TWJOTDJuM25VbkdUVkJjYTFnRU15Qkd5ZURRaVBINFJVcXZQ?= =?utf-8?B?Zk4rWmZvdnJIaUVuUEg4RjBWRGVxT095RUk5K0xVRXEyQlpCWWxPbG15Tzk3?= =?utf-8?B?NmR6eUNoMzAzVS9YZS9BejhSSTdKWEpMc3FueW9Na2czN3Y0UlhPb0t4TndR?= =?utf-8?B?TXN4MjR0dUQxMXBzdm1QQVJVVmhwZXd4d3VGTVFlSkM5d3cxcnpSL3Jidk4w?= =?utf-8?B?TjhZWDdYTlFCVVh3OW9KVnNmcWhGMTNKdXVMb1YwdEFKUzh3dXhrOEJBMUht?= =?utf-8?B?NGxkT0pyV0s5RWtmTXFkaExEQ2pibzF1Vkp0ekwwaGtEdmdOUWM1VEZ6U2ZU?= =?utf-8?B?RVJiRUszQkNLdVpVQ3FCRWlyV0FwMGl0dnRSS1diT3YvcTB0VVZFa2hGelJl?= =?utf-8?B?YjBZUzRiWWN2ZjJPeGt6SkNiUmgvZ2NZNFYrWTZFK0Q3RGFxdGhFQVUzK3Zv?= =?utf-8?B?VHlVN3JuNTEvQ1NzVXVnZ0pQdllxTHdtMWZ3bW5FbEZIcmRINGEwTzdoYXNq?= =?utf-8?B?d3lIQ3M2Zk9WYUZuanloRjRmamswaFZ6MFBudlQvVjZHZ1BtYW84TGY5K3BY?= =?utf-8?B?UnBSM3FrWW1wdkdYZDZWMjZlbGhvVno5RXVTSkFLZnR4bU5CREwydHNHR3l3?= =?utf-8?B?MnVNbURlaEV3ZkNoeXlkcWdGcUhwWDBwYVlzNXFPWDI0MkZxZmFhYkJ6ZlBz?= =?utf-8?B?MFZocVVmQXIzTXZMR1RBcVVGd2ZZTDYzQTk5TkpaY3dOZTNRdXpNcGFUQ21X?= =?utf-8?B?M1dGOW4xeXlNZHRSRkVNL25ONVZ6a3RXUGxSbEdJT1NKVGhwRHhQSlNVMGhX?= =?utf-8?B?MWlQcXA5UWoydU9PekorcTlGR1pYOWY4aHdiVHNGK3MyTldrNHBkMk9jKyth?= =?utf-8?B?VE1HQ1J0Wmc2RDJkUEdBcitNa0lZTW5BWDlhRWtjM1I1cSs4WS95NWVmYmZ2?= =?utf-8?B?SUd6bXE5WmxoeEU5NFFJUkxQdVZIRGpIY2xWdHFRSldkdmtkMUM4K3FpbHNt?= =?utf-8?B?WWZia1hLNEl6MlV6RGZLRWhNanVSUU16em1Ebjh3bGsrQkp4aUJsM2hCeW9j?= =?utf-8?B?cWVZU0g2dk1UZ2MrelNjV2oxZXppWDNPSUFhRHZvVklCc2c0MlRTR3A0elE3?= =?utf-8?B?RUc0Y29vanU1ZVZkSEVTRThlbnRML2xGL3NSRmdscHB4N2svVHplTnlFQ2FZ?= =?utf-8?B?WDFHaW1RUEllUUkvN29zb3lOUGY0dnZqa1lMQ3p3SFNmaGU1K2tpUUxiWGp6?= =?utf-8?B?WmpoNG5nTUd5MFFDWUI5RklkQkV2TVR6SkNYTm5aTDlPSVBVRWZqS21VVnNJ?= =?utf-8?B?eGIyZlBPK0JSUUMxVlQwaGJNRUg2TkhteEJMS3Z5WGluWk82VmJSa0dZRE9Y?= =?utf-8?B?blRSVnZ4NHBuRm9VZnFYZWhkdEU5MnEzU1ovZzVaeEp0M1kycGdFaDlsamJQ?= =?utf-8?B?R0FXYUJTWE93MFUwa2sxTDRIeWFDYm5XUDRQbnB4T1huQU13NVRpWkMxeHho?= =?utf-8?Q?JOXxXhhUQL0VmUUQ=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba0ba3f9-0847-4787-046a-08df35c33e18 X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB10650.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 13:47:59.2763 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jyD+p8aGn7lRPX51z0+0Kmb+hZyGXQjA6mapuwmJeddkFNh4hxWWmc1L33NJSlXKWZo/o6A1A2Bj0xGF6JuoFp1O4ZeCQoC9vnuNO5gXAH4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9370 On 10/29/26 3:30 PM, Andrey Drobyshev wrote: >> 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 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). >> - both builds, spec-ctrl on vz9.2.0 and vz7.16.0: EPYC-Milan with >> spec-ctrl=on,enforce starts, also with only one of ibrs, amd-stibp >> and amd-ssbd left; EPYC-IBPB, or EPYC-Milan without ibpb or without >> all three, is refused. Everything is refused on vz10.1.0. >> - bus-lock-detect and v-vmsave-vmload are build-tested only: no Zen 5 >> or Zen 4 client host was available. >> >> Changes v2 -> v3: >> - 3/6: keep spec-ctrl only when the guest also has the amd-* bits that >> give it the MSRs, not only the host (Andrey) >> - 2/6: pc_vz_9_2_compat first in the vz7.16.0 row (Andrey); TSX_CTRL >> makes XBEGIN abort, not #UD, and libvirt check='partial' still >> refuses a fresh start >> - 5/6, 6/6: commit messages clarified >> - R-b on 1/6, A-b on 2/6, 4/6, 5/6 and 6/6 >> >> 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 >> >> v2: http://lore.virtuozzo.com/qemu/20261029113436.93521-1-den@openvz.org/ >> v1: http://lore.virtuozzo.com/kernel/20261029095645.4173762-1-den@openvz.org/ >> >> Signed-off-by: Denis V. Lunev >> >> 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(-) > > Major: vz10.x AMD guests from 55.x-kernel nodes are left out (patch 3 / cover letter) > - The SPEC_CTRL gate change (AMD_IBPB_RET required) entered vzkernel with the RHEL 10.1 import, commit 9f055df113432, first tag rh10-6.12.0-211.16.1..vz10. > All earlier vz10 kernels (rh10-6.12.0-55..vz10) still advertise spec-ctrl on every AMD host with IBPB+IBRS, i.e. on Zen 1-3. > - Release-kernel tags rk-6.12.0-55.52.1.5.28.vz10-v10.2 and rk-6.12.0-55.52.1.5.22.vz10-v10.3 show shipped 8.0 nodes ran 55.x. Host-model guests started > there carry vz10.0.0/vz10.1.0 and spec-ctrl as require. > - After such a node moves to a 211.x kernel those guests fail migration, restore and revert exactly as in VSTOR-151770, but pc_vz_9_2_compat does not apply > to vz10.x. The libvirt kludge being reverted in PR 392 (d7e2f96f877f) covered every machine type, so the pair of series regresses this population relative to the kludge. > - Fix: enable x-spec-ctrl-compat for vz10.0.0 and vz10.1.0 as well, with only the next new type strict, or keep the libvirt spec-ctrl kludge until then. The other four properties are fine at vz9.2.0: BLD and VMSAVE/VMLOAD changes are in every vz10 kernel, TSX is host-config, not kernel-version. > > Medium: tsx_compat has no host guard (patch 2) > - kept = HLE|RTM whenever the vendor is Intel. The message says it "also covers Haswell parts with the TSX erratum" and that XBEGIN aborts. On > HSW136-microcode parts and on silicon without TSX, XBEGIN raises #UD, so a guest that selected RTM paths at startup gets SIGILL. > - Not a regression against the libvirt skip, which had the same hole, but the message overclaims. Guard suggestion: keep only when the host still has TSX > silicon, i.e. ARCH_CAPABILITIES.TSX_CTRL, CPUID.7.EDX rtm-always-abort or tsx-force-abort, and never when host_tsx_broken(). > > Low: Hygon hosts excluded (patches 3, 4) > - IS_AMD_CPU matches AuthenticAMD only. Dhyana (Zen 1) hosts lose spec-ctrl on 211.x the same way and get nothing from the series. Add the HygonGenuine > vendor check if Hygon is in the fleet. > > Low: bus-lock-detect kept bit on 211.x (patch 4) > - svm_set_msr rejects any DEBUGCTL bit but LBR (DEBUGCTL_RESERVED_BITS = ~DEBUGCTLMSR_LBR), so a rebooted guest enabling BLD gets #GP and one "unchecked MSR access error" splat. A migrated guest loses BLD silently since QEMU does not migrate DEBUGCTL. Cosmetic, worth a sentence in the message. > Disregard this. .211 is the first VZ10 kernel in our production. Ack for the series Applied onto hci-dev