From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id B4BEB80726 for ; Wed, 7 Oct 2026 11:58:49 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 697BvXFd004386; Wed, 7 Oct 2026 14:57:34 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 697BvXFd004386 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="wNaQp/YB" Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 697BvABc004343 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 7 Oct 2026 14:57:10 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 697BvABc004343 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-487038bc9b8so2636102f8f.2 for ; Wed, 07 Oct 2026 04:57:10 -0700 (PDT) X-Forwarded-Encrypted: i=2; AKwUvBwhTk3NJSEKMcOMz16ELN1JktMK7volU99j2Vn2HATR0d8YoJy6iSxgGk+mVPTqLSPxZdH3kw==@openvz.org X-Gm-Message-State: AFq9FYLusi9kVHVVoWBoTIGaCPdOBjE9Uvk4Z/rlnJ4D9wEjQqDAgMOr 4QGSOMgZH6AiyHM0XNi7M8NKOAC6DCj84wpYZj28XeyC4aQp1xyrBKW0yqs+nbKk2mmlx5/XSzT m5aWOF5DMRPyuRSIwz2jV4DDVRnKtaTDtfXAWMPhD9DY0mrN+JapUtA== X-Gm-Gg: AYBFou2pbKfKyPK1C+PD4sasMikgIGGTNiuO72RQW0LKUlYe4xnLHxE0wZiuhhW3PlJ CfXaBcXIsbJ7lvJ5C+Ximhf3F7m05vfW6wJ3mtb1/x+tsrdjUxh0ADhKJuewNIbEMl5hSu20inb qzyNklllPgbsOo/4z4zMETVwvuoiboi1suH+MkD08I88ekwRA6I+nwUuV32ddruB3Icip0KP0Y2 Ex4DLWEc1wfMq3SM4jNZ6sXHZsEt+vrKZp0nWf7JbT3Dy/38ILWCrkedz4k3BH2yJ/Y8ECRKQ/T w2TKGZnZ9jYHKpCYTzmWdtq+NlN8mW4m1c8Bd8TaHjq1PS0v+44HivVbTaTrDvrR2FfyIvJqJxF iED0ftEsQ4pMxupLf X-Received: by 2002:a5d:5f92:0:b0:48b:a6:61b0 with SMTP id ffacd0b85a97d-48c7289c820mr4245331f8f.47.1791374228544; Wed, 07 Oct 2026 04:57:08 -0700 (PDT) X-Received: by 2002:a5d:5f92:0:b0:48b:a6:61b0 with SMTP id ffacd0b85a97d-48c7289c820mr4245273f8f.47.1791374227848; Wed, 07 Oct 2026 04:57:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791374227; cv=none; d=google.com; s=arc-20260327; b=QXEe8b9MDoeDp7qJ326jzuTJXRNr6dFaw4Wpzbtdu9O0R7YnVIcsRefi+TACzW8A3a Jd4paUGDnxm8O+t5yHpha/vaNo7hc0KRWZxJRG2L6NLnuCW5no2wj16Lpg5NvpRQnG00 THD5SOBt5Efb0HzygzWVCBzf4ODGBZUT7waevqSRm3tdI5RsGnzuzr3RqbZWehaxCG9S LUd5sHrEPkts3ZGgUXrtJFE1ocgTPLUAlhkiwuZ9vo6eJjjx0fXgyVdP3tqaDkCu75LK XesBfsoiRXagc3u6LHIVtFhlAg1ApmGzrotVsLgFL0aJzYSs3gTNOLzwmcLGjE/8pOnL 2lHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:dkim-signature; bh=e9EKnpV2MaHKO+hdQBxf6gr0jwr3vfCneJGKZ/vrBF0=; fh=bRkZfFa6377EgOVW8zBDri2gGIQqe/ZeiH+ijEM/ROI=; b=KDsMrgvodhRrysba4wLiQuhPvBMJxvcjKtH20o/l6P3nngUuWE+CZGcT/BJoiKF9DQ ngGtDj5ova9ED6Kt0hQddKqD9k6FFsZnAf2vbtZxCftaAJdrNBAKl8qx7lTD7D6nhDS/ lwIwl6WJForOBtieSMs3KTo4eRNg5llicf5tXt/vekSW+TGeBgW8rDvelTXQydQJy/eQ 0ZMijB7DUoDFxfJBv/bNPi6Mkzh5gj6aElxK1M1Yqt1Geaavi/f56QaeDCsEVcQtztj6 XW6NT6Qu5VgFh8r05q8GPTo1dIypJFmMfz3D0OZcJt5OvewnMq6zRJJ+6EhBHxqssihg eCeQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b="wNaQp/YB"; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-48c724bc398si4281578f8f.464.2026.10.07.04.57.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 04:57:07 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b="wNaQp/YB"; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Message-Id:Date:Subject :From; bh=e9EKnpV2MaHKO+hdQBxf6gr0jwr3vfCneJGKZ/vrBF0=; b=wNaQp/YB3aKGSyJbQ25 BHq+Kc6WNrt4nsjLBr9UFXKl+0bi20dSJ4+AezQPv1ufGUC3pNZfI6c964jsL+coG8T+pnLBqpzDl X3pQU8dbBAwkDX1QDI+33c+6MqFqjUXEgKxlWEKZXNrNtfhV+MoSaOVA0MUhDG5LGDqsxjLlzOErC S4esDwr5/IsGjnH6xaiEyGz3VnRC+7caeFdSNnmMjpzyn35YruzLC1Xy8SL00E9IAl8oGv+8jD3kZ Bl6+W8VN9A9HgbGEKjd/WYsqP5AHWz9jThQl44yVPoAavjk3QC3O/g8h7NZ2uCG4vFc27zl89I/7l YbDN3cnd7MfNgUQ==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1xEQDR-002m3X-0K; Wed, 07 Oct 2026 13:57:06 +0200 From: Konstantin Khorenko Date: Wed, 07 Oct 2026 13:57:01 +0200 Message-Id: <20261007-b4-prep-khorenko-vstor-148656-cpuid-v6-0-a8eb906e69b8@virtuozzo.com> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAI4zxmoC/53QsU7EMAwG4Fc5ZSanOE3chon3QAytk9BwoqnSN oI79d1Jy4JEB7jRsv39lm9scim4iT2ebiy5HKYQh1Lgw4lR3w6vjgdbaiaFRBACeaf4mNzIL31 MbrhEnqc5Jg6qQY2cxiVY3mrSxlQOfFOxIpUFHz72lGfWU+DNGdjLd2NaujdH85axjfZh4z73e zLsC/+KzsAFrxWgMF55UbVPOaR5iddrPFN831OzvMOVxfVoAYyk2qI4cqs73Kq4gKCga6gVtT1 y1U+3/puritt5QJKmc61UR66+w9XFRS1Jk3Ea7a//ruv6BZVSCKBVAgAA X-Change-ID: 20261006-b4-prep-khorenko-vstor-148656-cpuid-a5c5993e1f83 To: Pavel Tikhomirov , Vasileios Almpanis X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=7827; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=JeZKwdRE9hxGF6p0Mxdl2jhRhoG73B8sR/O0BfJbi/c=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBqxjORtEhhDgMxs4G/rlYlhcQMm9laQSmJ7r4lG aRegUL7yi2JAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCasYzkQAKCRBRlgpH+WFc Kii0D/4no4G4fyYrBUVuTc3LEC/TTZStrtPMj4970HozgCBi315socWdVZNAAuAsu3US2qQi5Z4 SewjwodgZEsKprJf5lHWjP+TPCMtvdXPSXesMZOnR5D0vzWjopO9oR3PrJ6QCBXnDthiPEOp4j0 5H5aOghfrqN2RCN7p2y33unZFXGi4QSRupYgaBSykf5CcWXPjS+UVa8/Jq5nB8rAWRqdJRndogw LV4za4BzZWmMxTzzitU27sd0LyP/QMpMm28Rux3V/XZDUlAS0vMpH7yrSjJYBxKKGM+2LnviT0w f6Nwq43otps6vDrcp/NI2FjGCIddljYVp1H1K0MZhpgpM59dXh5NufjHMiQ+8cs112FYd/jnN7B cNVPkX6NorxTaiekJGGEWl7sk7K1sIlZe83rgaCUkB8idHgUY7txjRnXwEHbt98OZfnzZYTNkEJ Qt6AWdu6W5pwHUP39f1tJkChT1wgK9i5iLEw/747dZE9LQXo6E37tS5krmjP9DFs0YJ8qORrcaL mDUmGYFKU1XMm6IofQRXbypC5cIEedrtDamNhzVD96F7Jv8ZC0mR2upTRMnOB6Dzmt/DAIyI6YY /r2rJRFL/bioV5XY54i6m2iH85oIjXAE7JVAq8vUyc3Ggt3+n6rEDkKNcKR5hUy8lAXEpN/BpHz o4uYzfLgV8VCRmg== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Cc: devel@openvz.org Subject: [Devel] [PATCH hci-8.1 v6 0/5] x86/ve: CPUID override follow-ups: arm at once, prefixes, selftests X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org VSTOR-148656, every Container start dying with SIGSEGV once /proc/vz/cpuid_override is non-empty, is fixed in 22.8 by 07338fbae5a3 ("x86/traps: emulate CPUID faults for user tasks in exc_general_protection()"). Working on it turned up two more defects in the same feature, and the fact that nothing had ever exercised it. This series takes care of those. None of them is a 22.x regression, all have been there since the vz9 port. Patch 2: ve_setup_task() only sets TIF_CPUID_OVERRIDE, the MSR follows at the next context switch. A task entering a VE through unshare() or setns() executes CPUID natively until it is scheduled out and sees the host values. set_cpuid_override() flips the MSR synchronously for the current task, the way disable_cpuid() does. Patch 4: check_cpuid_fault() compares two bytes at ip with 0f a2. A CPUID with a legacy or REX prefix faults the same way, but the handler sees the prefix and the task gets SIGSEGV. Use the instruction decoder, as fixup_umip_exception() does, and advance ip by the decoded length. Patches 1, 3, 5: selftests/ve/ve_cpuid_override_test. Each kernel patch gets its own case. The test saves and restores the table around every case and tears down in the parent, because the kselftest harness skips a child-side teardown after a failed ASSERT. Tested on sqvm2-4060, the node of the failing CI run (Broadwell VM with cpuid_fault, cpupools-features 9.1.7, so the table is armed at every Container start). With only the 22.8 fix, cases 3 and 4 fail the way their patches describe: host values, and a child killed by signal 11. With the whole series all four cases pass, repeatedly and on a non-empty table, and the vzctl-pytest start cases from the original ticket pass as well. https://virtuozzo.atlassian.net/browse/VSTOR-148843 Signed-off-by: Konstantin Khorenko --- Changes in v6: - Patch 1, 5: build the test for x86-64 only, decided by the compiler target in the Makefile since ARCH says "x86" for 32-bit as well; the prefixed CPUID goes back to a plain "=b" asm, the 32-bit xchg around ebx of v5 truncated the callee-saved rbx on x86-64 (Sashiko). - Patch 1: say in the comment and the message that the context switch the parent waits for need not be the stop itself: any switch after the count was taken arms faulting on the way back in (Sashiko). - Link to v5: http://lore.virtuozzo.com/20261007-b4-prep-khorenko-vstor-148656-cpuid-v5-0-652c5c9e56da@virtuozzo.com Changes in v5: - Patch 1: the stop is reported to the parent before the child leaves the CPU, so the child hands over its voluntary context switch count and the parent waits for it to grow before SIGCONT; a SIGCONT in that window would have let the child run on without a switch (Sashiko). - Patch 1, 5: CPUID through __cpuid_count() and an xchg around ebx for the prefixed form, so the 32-bit PIC build is no concern and the Makefile gate can keep ARCH=x86 (Sashiko). - Patch 1: a failed table restore in the teardown fails the test instead of only logging; skip without root; log when the teardown cannot mount cgroup2; wider buffer for /proc//status; the header says one instance at a time (independent review). - Patch 5: early-clobber on the ebx substitute register in the prefixed CPUID asm, as has it (independent review). - Link to v4: http://lore.virtuozzo.com/20261007-b4-prep-khorenko-vstor-148656-cpuid-v4-0-bf16c29bea24@virtuozzo.com Changes in v4: - Patch 1: a child that exits before stopping is reaped by the ready wait, so its pid is cleared there and the teardown cannot kill a reused pid (Sashiko). - Patch 1: spawn leaves the VE cgroup before any ASSERT can fire, so a failed fork() no longer leaves the cgroup behind; a child killed before it stops is logged; the teardown is described as running in whichever process survives the ASSERT, the harness does not run it in the parent on that path (independent review). - Patch 1: use write_file_at() instead of a private copy, renumber the child exit codes, say "at least" in the too-large table message. - Patch 1: record the child pid right after fork(), so a child left stopped by an ASSERT between fork() and the cgroup move is still killed; say that a harness timeout leaves the test table in place and that the second case proves nothing without the first (independent review). - Patch 1: name the fix the tests detect, describe the host-side and fallback checks as the one masked bit they are, log errno when the table read or the cgroup2 mount fails, rename the two table buffers apart, -Wextra clean (independent review). - Link to v3: http://lore.virtuozzo.com/20261006-b4-prep-khorenko-vstor-148656-cpuid-v3-0-16141b8ca07d@virtuozzo.com Changes in v3: - Patch 1: a saved table the kernel cannot take back in one write (a page or more as printed) fails the setup instead of being silently left behind by a failed restore; writes replace the table, so there is no way to restore it in pieces (Sashiko). - Patch 1: the child pid lives in the fixture and the parent-side teardown kills a child that a failed ASSERT left stopped in the VE cgroup, otherwise destroy_ve() fails with EBUSY (Sashiko). - Patch 1: the Makefile keeps ARCH untouched and decides on a private variable, lib.mk picks the clang target by ARCH being empty (Sashiko). - Link to v2: http://lore.virtuozzo.com/20261006-b4-prep-khorenko-vstor-148656-cpuid-v2-0-f6d1192c7d60@virtuozzo.com Changes in v2: - Patch 1: the child stops itself with SIGSTOP after entering the VE and the parent resumes it, so faulting is armed by a real context switch; the pipe handshake, whose read could return without sleeping, is gone (Sashiko). - Patch 1: setup creates the VE cgroup last, so a failed ASSERT in setup leaves nothing behind; a failed restore in teardown is logged (Sashiko). - Patch 1: drop the EAX comparison after the fallback to hardware, the child is not pinned and hybrid CPUs may differ per core (Sashiko). - Patch 1: build the test on x86 only, add the binary to .gitignore (Sashiko). - Patch 3: the no-reschedule case repeats the sequence, a tick can still preempt the child in the window; with the handshake gone a child that dies before reporting is reaped where the result is read and its signal logged (Sashiko). - Retested on sqvm2-2084 with the whole series: all cases pass and the table is restored; on sqvm2-4060 with the stock kernel all cases fail with the expected diagnostics. - Link to v1: http://lore.virtuozzo.com/20261006-b4-prep-khorenko-vstor-148656-cpuid-v1-0-741609f4f03a@virtuozzo.com --- Konstantin Khorenko (5): selftests/ve: check CPUID override emulation for VE tasks x86/ve: enable CPUID faulting at once when the current task enters a VE selftests/ve: check CPUID override right after entering a VE x86/traps: decode the faulting CPUID with the instruction decoder selftests/ve: check CPUID override emulation for a prefixed CPUID arch/x86/kernel/process.c | 12 + arch/x86/kernel/traps.c | 16 +- include/linux/cpuid_override.h | 3 + kernel/ve/ve.c | 2 +- tools/testing/selftests/ve/.gitignore | 1 + tools/testing/selftests/ve/Makefile | 6 + .../testing/selftests/ve/ve_cpuid_override_test.c | 357 +++++++++++++++++++++ 7 files changed, 390 insertions(+), 7 deletions(-) --- base-commit: f5d1fdcfffe101fe2bafa7df09d95d2e811c5c5e change-id: 20261006-b4-prep-khorenko-vstor-148656-cpuid-a5c5993e1f83 Best regards, -- Konstantin Khorenko _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel