From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a188c56e81-f25db457-c9ef-4c0a-bd75-043c5097420e-000000@eu-central-1.amazonses.com> Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazon11020141.outbound.protection.outlook.com [52.101.84.141]) by lore.virtuozzo.com (Postfix) with ESMTPS id D3FF58017D for ; Thu, 29 Oct 2026 17:46:47 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jAUqTF5RuC5VsGk2dwibvgh25yfZfnGKAcB92ky1N0Z1hrCaJE9O055j5E7vm8mU20oUtyk3JpKcx+h6B1E+BxtjPLeyw81DGJx6A/mixk0wi/SpocgjXPVyxsh8AEN2PqghSP12HX5H0bMt5UyPW9lsJA2dNqAfK8ItByxjTq+zShk+4QjTSpbyoyETiUav58MLV708VIA0Wd+dyqdtVPPYuLlC5xvGEh2NYFtYsCpvwX6/qK7bpOBi16QYVPS7JMimlrkGykxghEfoX5Rtil8dv9lWrw3ZampNK6buB4mwcHEO6+tLjuBZ0nezUNiHQ9FTHomT44athZnv5ZmUTw== 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=O4Njc6YTNHtiHJk7FGbdHUACXMtHrEdzmP9YmEPq6RY=; b=WHnJnBaf/DrAwLdrVq1lMnwKPBqNg43Oaa36kpG72sidg6yRPBAXOOmHZWfXK4J+8bSS6so30a1COZirdTcwLxbRxIzLl8RAZJRbsRlAU2SR1b7CsioKWr5ISKhIBBTylHvdxtvzJql9uYPJe28C6C7NFqLVMXoETCJR4dZ/3WfHeeSbkWLBu0oe7tsW7uEKK2edVlSpKcv49x/FA9LvHqTvDtaYntZfTCmPZxHH6EIflglqcocnch8JCD6HUh4yI2R06LyQvGDyY/cLQz+GR5GcjQBNUvibrIMb/tKAZFQSz3hCVLRdHySAmKt+QKWdzgjlM/XYiOBYKXPJib7gNg== 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=O4Njc6YTNHtiHJk7FGbdHUACXMtHrEdzmP9YmEPq6RY=; b=B5CFoM+npOvJ6NAue8aEoZMyewlHCv60UyVkeGhxCsQcGBsi6isowMBPDQPK0z5grIxJl9KkNs1fmk1CT7PEEBc71GAGKyfY03+DyuR88FLY4S5Y1ZRdxUdOJhR2nzY0DDUSOVGJuA0MNTJCsxkrlr+6G+khHbERMAPkm1SWLhE= Received: from PA7P264CA0255.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:371::11) by AM9PR08MB6289.eurprd08.prod.outlook.com (2603:10a6:20b:2d7::15) 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 17:46:43 +0000 Received: from ZR1PEPF0000E6AD.eurprd05.prod.outlook.com (2603:10a6:102:371:cafe::82) by PA7P264CA0255.outlook.office365.com (2603:10a6:102:371::11) 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 17:46:43 +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 ZR1PEPF0000E6AD.mail.protection.outlook.com (10.167.241.84) 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 17:46:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793296002; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=FnOgVjl1+aOERSvYxgoT/fzpThfo3eBm+For0kTvPmY=; b=bcAkmNFh3z+euZh6mIF+Pd717moMIvyfhmYX0O457yzpO3Yhg9by1m78HxBEdl0n t3mh2b0eKWem33wE2ZUVljM8qFI0NN1dmCwF//iV6QItEgqzmi5OpZ2tzomFlsFc88a BpAZyMGKd60YMcmbK5ghcd7tMWomlo6aX/Lv5mxS3ySjES+zF/CdKL5NR4MlbO07sy0 K8O2ftNk5bOLC1y9VM0J6NP3iS42yVyxBfvTZ9G2byckt2F7WeqkiCn0MWHJjaGt93+ Df2suLfGCeMMAjNv26e2tbOKaI3zxBHJS8wk8vTAIdzXgVuCP5l6bvsFWHFXkcssg5w zyr3XcHebg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793296002; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=FnOgVjl1+aOERSvYxgoT/fzpThfo3eBm+For0kTvPmY=; b=OLL3LLmhQHmY4W5MCtaFCkmFB6DZZKS5u0KDIJmhMiEUP06b5pFHy3zbw8NwBHau YyxoQ4d4HrrDMM705I72goLS2BursyLQyxbccCWLK8t2hwlSamcd/DHFpFfxR/Itkf+ HhrAkcHBF3gVrKq9+KktQ0ued265jKyglwbF8aSA= Message-ID: <010701a188c56e81-f25db457-c9ef-4c0a-bd75-043c5097420e-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH hci-8.0/hci-8.1] i386: hide la57 at fresh start on vz machine types up to vz10.0.0 #VSTOR-152405 To: andrey.drobyshev@virtuozzo.com, "Denis V. Lunev" Cc: svt-core@virtuozzo.com, den@openvz.org In-Reply-To: <20261029174221.1068858-1-den@openvz.org> References: <20261029174221.1068858-1-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2026 17:46:42 +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: ZR1PEPF0000E6AD:EE_|AM9PR08MB6289:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c9021d99-2ef3-45c3-9e01-08df35e49824 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|61400799027|32142699015|376014|48200799018|9140799003|261028144727099003|261021121427099003|56012099006|261026135527099003|5023799004|5063699009|261021123027099003|261022075727099003|261009223027099003|261022105027099003|261026121527099003|261026140227099003|10067099003|16102099003|18002099003|55112099003|22082099003|4113699003|5113699003|3023799007|13003099007; X-Microsoft-Antispam-Message-Info: 1D46jIQSQnWn1lU7CvgYxFEMTcmc7HzV9C8m6+Wb1bhNe88BsmlMT5T17dIjJN2ZVY8F/9pNLua7VqZGub9cokaAOsyLyfVkiDqS1XjtS8CxSFZpHmVlpYbt7yj3wbGLO8taa5IuuQdj+JUTi5uy1l4DDZB0/JFlpFnW1lxgMYvQgw9T9XNZ44d7i0xTAlnuoZi36/PmqMNHDF1qegmmIjn9Qx+Fh9cvd/q2F/YMt57f1mR0nNqjh2s82QUqVMdO5lTUC+mBeMyCZLbcNqwZ41U2SdN0rrU3tZ5leaI53rOA+hJGbwSv9PA0z4W41hAWW2a/68hze3KsHeYs64+vUH5yZe3VQYAiaH0OQ46rlS9hgMvTkGTUZVE7tF7xCZsiPVri3hEsW+dsXLQyvkHmIuZeBpPcgkCEUUD4nC5lzF9o3z3G+0ysOMZdb0ZFSMwmbi86bmAetZzJF5QYX7K7l1BRwF8brP59ahFAvnMcKn/LkvCGct3AFdm4ufT6gSmHUEbnpl0Xru4LYzrCR0yd7C3uWt4gIsKAo1mWPdQF35Vsyu3Vixl/0s10MFjz9tjEmPqqBja4MR191pFgkdcnqPWYm1K4h2lJWbA5vIKaoybGCkYHyc1yjATiLtzj8HWfU534D4mRId6Dfy328Aatw6TKOZ5baHIWNSL6R9eCo+HneX9seK9sb66lZHKiyNjtenJ9iAFQ02oY4cXSQkh60o66VOuPc/kIFt2R/fdgekzNuFVozbL2xV83VNMkZd4Nt0UDHPP8D8WigZy58esmwaiLgDrkTyC8ukynK6mT5HCd9gPNIfWHu7LZGor1hkzO13gKLEHNN61J4vq5lH4v1u+VAwGgq95NcYvD1z7jQqCATuy8H3HHtfztvsmNMLBDniz87fXBKfVXPfQL6L7j+g== 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)(61400799027)(32142699015)(376014)(48200799018)(9140799003)(261028144727099003)(261021121427099003)(56012099006)(261026135527099003)(5023799004)(5063699009)(261021123027099003)(261022075727099003)(261009223027099003)(261022105027099003)(261026121527099003)(261026140227099003)(10067099003)(16102099003)(18002099003)(55112099003)(22082099003)(4113699003)(5113699003)(3023799007)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: hU+enDxEo0vdDR2ErGNNNOqRj5jQxY3N2rNPiwKeeREMWojFTOVH4r4/v/aLC5wA70bFk4EcqEeqz7+ED87MxS+ZkPxaqbwU7xxLhJI3PrZW6yprjLr0I+5sxphV1dbODQQZDxhuZMTxFbWEQqaBjcWSQhESE53UUZLoIsPuT2ummPyf/JBUZ/RJ3zFUNTUp0wfIIRlFyuYKT2c62HpacUSJgFvFkQFl1rxsaw6wno0B+5UQjbQWXk/zNsZ5XCDsEAjmo1nslopk60l8vMTHqxITDqO86Qb1zpANOTt2fwXD2HHWuUnU+O1V2Hn6IYZgJ0Wda5UODAo7P4wMeaEq+2l3n2lPRt9JaX7hpwbWxwNL1VJuhDBfwy0EvuKNiS4nr956GuAi7IKPpijSBq1DUXjfq82KqOaXgov8xWO22dx+3cEEKcTXBDoML2udVPaP X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2026 17:46:43.0647 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c9021d99-2ef3-45c3-9e01-08df35e49824 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: ZR1PEPF0000E6AD.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6289 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] i386: x86_cpu_hide_la57() hides la57 again on -loadvm restore - [Low] i386: x86_cpu_hide_la57() uses runstate_check() outside !CONFIG_USE= R_ONLY - [Low] i386: x86_cpu_hide_la57() also hides la57 for -cpu max, not only -c= pu host -- commit 0fe19500ac631308cc76d8b2992da28d4b1f5fb1 Author: Denis V. Lunev i386: hide la57 at fresh start on vz machine types up to vz10.0.0 #VSTOR-15= 2405 This adds the x-no-la57-on-start CPU property and enables it in pc_vz_10_0_compat for vz10.0.0 and older machine types. On a fresh start under KVM, a "-cpu host" guest loses la57 unless la57=3Don is given. An incoming migration keeps la57, and a hotplugged vCPU follows the boot vCPUs. > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -40,6 +40,7 @@ > #ifndef CONFIG_USER_ONLY > #include "confidential-guest.h" > #include "system/reset.h" > +#include "system/runstate.h" > #include "qapi/qapi-commands-machine.h" > #include "system/address-spaces.h" > #include "hw/boards.h" [ ... ] > +/* > + * Reported as filtered, so that libvirt records la57=3Doff in the live > + * definition and passes it on to migration, save and snapshots. > + */ > +static bool x86_cpu_hide_la57(X86CPU *cpu) > +{ > + CPUX86State *env =3D &cpu->env; > + > + if (!cpu->no_la57_on_start || !X86_CPU_GET_CLASS(cpu)->max_features = || [Severity: Low] The commit message and the cpu.h comment describe this as applying to "-cpu host". Is that the intended scope? X86_CPU_GET_CLASS(cpu)->max_features is also set for the "max" CPU class, not only the host class. x86_cpu_expand_features() uses the same predicate to auto-enable host-supported features for both. On vz10.0.0 and older machine types under KVM, "-cpu max" guests would therefore also lose la57. Should the commit message and the comment mention this, or should the check be narrowed to the host model? > + !kvm_enabled() || > + !(env->features[FEAT_7_0_ECX] & CPUID_7_0_ECX_LA57) || > + (env->user_features[FEAT_7_0_ECX] & CPUID_7_0_ECX_LA57)) { > + return false; > + } > + if (DEVICE(cpu)->hotplugged) { > + return first_cpu && !(X86_CPU(first_cpu)->env.features[FEAT_7_0_= ECX] & > + CPUID_7_0_ECX_LA57); > + } > + return !runstate_check(RUN_STATE_INMIGRATE); [Severity: Low] Will this build for linux-user and bsd-user i386 and x86_64 targets? The only declaration of runstate_check() is in system/runstate.h, and this patch adds that include inside the #ifndef CONFIG_USER_ONLY block near the top of target/i386/cpu.c: #ifndef CONFIG_USER_ONLY #include "confidential-guest.h" #include "system/reset.h" #include "system/runstate.h" But x86_cpu_hide_la57() is defined outside any CONFIG_USER_ONLY guard, and x86_cpu_realizefn() calls it unconditionally. kvm_enabled() is (0) in user-only builds, but that does not remove the runstate_check() call from compilation, so it would be an implicit declaration there. Could the helper and its call site be wrapped in #ifndef CONFIG_USER_ONLY, or could a user-only stub be provided? [Severity: Medium] Is the la57 bit hidden again when a guest is restored with -loadvm? Here only RUN_STATE_INMIGRATE keeps la57. With -loadvm, the vCPUs are realized during machine init and load_snapshot() runs afterwards from qemu_init(): if (loadvm) { ... load_snapshot(loadvm, NULL, false, NULL, &error_fatal); -incoming and -loadvm are mutually exclusive, so the runstate during realize is PRELAUNCH and x86_cpu_hide_la57() returns true when x-no-la57-on-start is set and la57=3Don was not given. If the snapshot was taken from a guest started by an older QEMU, or without la57=3Doff, the guest may already run with CR4.LA57 set. After -loadvm the vCPU CPUID lacks la57, so I would expect CR4 validation in KVM_SET_SREGS to fail or the guest to misbehave. I did not confirm the KVM behaviour in this tree. Is there any check that detects an la57 mismatch between the saved state and the restored CPU? As far as I can tell, nothing in QEMU enforces consistency, and migration depends on the management layer passing la57=3Doff to the destination. The commit message notes that this libvirt step was not tested. > +} > + > /* Requested features that a vz compat property keeps despite the host */ > static uint64_t x86_cpu_compat_kept_features(X86CPU *cpu, FeatureWord w) > { [ ... ] > @@ -9404,6 +9426,10 @@ static void x86_cpu_realizefn(DeviceState *dev, Er= ror **errp) > } > =20 > + if (x86_cpu_hide_la57(cpu)) { > + mark_unavailable_features(cpu, FEAT_7_0_ECX, CPUID_7_0_ECX_LA57,= NULL); > + } > + --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026102917422= 1.1068858-1-den@openvz.org?part=3D1