From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F27DC02182 for ; Tue, 21 Jan 2025 17:22:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4ADEB6B0085; Tue, 21 Jan 2025 12:22:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 45D776B0088; Tue, 21 Jan 2025 12:22:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 325276B0089; Tue, 21 Jan 2025 12:22:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 140A96B0085 for ; Tue, 21 Jan 2025 12:22:50 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 909C4B08CD for ; Tue, 21 Jan 2025 17:22:49 +0000 (UTC) X-FDA: 83032128858.03.3C72BDE Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf03.hostedemail.com (Postfix) with ESMTP id A883C20010 for ; Tue, 21 Jan 2025 17:22:47 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2Lgqyu0D; spf=pass (imf03.hostedemail.com: domain of jannh@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737480167; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BKf+c2A4MqpyaYk1nzTP+iHTyRogmgqheZB2Gvk79z0=; b=qEHQFGwM/0X28U4Rg6xwqqaCyUUNCQfGs76brx5Pxcm1vxGn8ggfK7QgzDs6PAEjJ9GQGc tNZkdVhnrXuoVJkStN1JvXjn/M8zIWh/s4XFv5ZcNujHBUxaQtDE9tlnfzVh9Que9L4h/b 42Jpk+UVFUZ2mLKU0f/B//+eFh5V2os= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2Lgqyu0D; spf=pass (imf03.hostedemail.com: domain of jannh@google.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737480167; a=rsa-sha256; cv=none; b=dzEueHfdfy2YdmGvck/6GqXYC9aTCKbHfTGNSXvEQAnTt8kD9aJ8NdL+T/lB0X7OrF8q7v OXThYckNP552+kSNlRd02x5qf8VtxgnBNvFZ9n1JT/dz7OZYLJPcLOqA+Ol5b1Zm31pxXS lKmuEl4O0mRLHo8nJRVWIJpyi921RzU= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5d9f0ab2313so22258a12.0 for ; Tue, 21 Jan 2025 09:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737480166; x=1738084966; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BKf+c2A4MqpyaYk1nzTP+iHTyRogmgqheZB2Gvk79z0=; b=2Lgqyu0DcYSvBrNNWtgT6lbokyvzOr4xQ9b8SKk1LjMLTGRUoDUPfFORtjrLEFimx7 rZOQiwZKHqRhJwa6lL+jx8Jvb1gu2VHCc4/5hJ9Tujgab7GkSFTqfdn5xkD91zhJSLBC DPebBN1wiFxGNrEzVzEt1VdcZO+9YLtbuejaE8zlE4HWu0XXOnNYzDBvqv7pRcSU1c93 s2STJNtq+moHlJoxe7xDiYL9B5DQHRZfWiSWLkomtDJJwm6/A52SGsN7nyzlYaxzZb/n XTCMIjD6REsIJcxO03l5msFOttMs5F8rcgnz1TCBHVPMysaYokrpSP6nEoXhkHOodl7/ vvdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737480166; x=1738084966; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BKf+c2A4MqpyaYk1nzTP+iHTyRogmgqheZB2Gvk79z0=; b=XmNLgyudTxJty4kKbAh7Z0VA75LkAPlHFTE6lX9t6N6JHPpM/tfhXidm/RwM2NLXSr L6i9i1wkqk1GF6TjaWJllizsj0YwyvI3KQiF+gyuvpyItu9+3uqRVQUppgFJoTLN3pZY WJcEWfxDbGyKW95TJ7qi/nsbMR1urybYivl7mRMe/VaxjfqlhUV4dRNG++rBtSAKuq5L +SRfX2ifAmW2nL8lvD7xyuLJttBYR4snTDnvickoH9T2AbRzeCkTpR/8dv0Ptatd5knC tDVVmUMMRZoVJKgEE+/AE4lPXLidnp+bcuvm5B5NVucXn9IzeetglL/DfaII8+acmK9v GdJw== X-Forwarded-Encrypted: i=1; AJvYcCXzjn8mB82emB6TOJYkcp2/TQdU8la6+T45likU80I9GKinwlUKua5slPeJrqUdK0qAHsS5b8FA6A==@kvack.org X-Gm-Message-State: AOJu0YwpAFz5sNVcCOwIV42uVIbQjZm0kbJgUq2U3902VdkWESsVJKDo e7oFiEZqo/1h11HrhSJEn55/WoTgx7GY3nuWOJLt7U4XDI9XOAbslJU3UUcwlYYZbNdfv/004pA P7ZlUpRWg+iPHq79IIdukWjAUIgIc+jZAKDv5 X-Gm-Gg: ASbGncvVQKV0RkRDVIEK+lvscn8jzC5QH/rDt4RHZf+tHUUH6tTPoGFpzVRq6H72WYL Df6Y/+Lpsg+RMVSXSUKEpRq7H+MSwRNRcU4n/+6SHeH8dTdrpB/mm6F2DCewXnI6BZZJcWdspAj hzQUg= X-Google-Smtp-Source: AGHT+IE7WPR0Tx3eJaxVEdh8qZu+rZHSf0G5we4rSkH6Jhq3T3xezxHY/6/sDNSMAZRc8pPS2m5lnV4tQ7CxKjvsLpM= X-Received: by 2002:a50:d64f:0:b0:5d0:b6ff:5277 with SMTP id 4fb4d7f45d1cf-5db90b16c0bmr243088a12.2.1737480165525; Tue, 21 Jan 2025 09:22:45 -0800 (PST) MIME-Version: 1.0 References: <20250116023127.1531583-1-riel@surriel.com> In-Reply-To: From: Jann Horn Date: Tue, 21 Jan 2025 18:22:09 +0100 X-Gm-Features: AbW1kvaou8HD7qYiA8-U0b5k8ibEuS-3_wypb7D7RrWos8Fsw0txXUNFIXeNwm4 Message-ID: Subject: Re: [PATCH v5 00/12] AMD broadcast TLB invalidation To: Michael Kelley Cc: "riel@surriel.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "bp@alien8.de" , "peterz@infradead.org" , "dave.hansen@linux.intel.com" , "zhengqi.arch@bytedance.com" , "nadav.amit@gmail.com" , "thomas.lendacky@amd.com" , "kernel-team@meta.com" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "andrew.cooper3@citrix.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A883C20010 X-Stat-Signature: ykma4p3wa4qdszc4bkxpun8dbnd9dcyg X-Rspam-User: X-HE-Tag: 1737480167-102825 X-HE-Meta: U2FsdGVkX19iTBbqjm4CtwTYEe6CBEN+ABfvgsOkppFbM+eKFsN3mkBht+ztjuXndFBFkrBeoeXosmtAYOfrC5qjjBzwf1G5F0YlVJzNheX7picBr9YmbTQt+9dgLDgS/vhX5fO+4GFJTboBVsHsPF2D6TxNPgN2OQGuIdKOKv7/kHJajLDGntv6xyQGjRPGlyj82tN1l8QwZzM/MnhiFb/VGu/D8cj83Q93udpAxJET3lZbnnPL1wpefPff4bpLJwbf2sWTrHQxpwVUTE0wD3/nrMUm3QLB9G3GW1fj1VHJ/zWNt1l7352E0uo8aVTieHdVXO+cfUWrAEug8Hhv1rtdDiLr17kuBWRvgM0fdiM1qTuGyxcviEwWKuJ2Nks+k/QoEAeUCgMp026egxjP6h2pCfPHsC7TQD8UgN5fBh7gta57pfna553J0U8G2DyCkRiskR8c70qiS2wf/Y4LqxOFeaQ4ioEv+KUCdT69nNSUusmihL3mkRFjVXge6FMzuzInnjVYaGrV7vLVHdSdAdbRo7YtpdiX9v85kSJrTZiLAlrNfdWEtaxyaGi+e0imjBToIiiS1SOVd2GkQ9bRSe0IsBVDjWkCOguNJJzRq//amSdNpxezlDUmul0AvcVXPIeBKD7xB2YH+RgtpMYVefzGsDD+pT6mYAMGVxdyLOUIMGfX8STUyQgSJsfndcpchcMRJWAh9hieRkRGcX9XA2bd1RLIW4wUHGupn/kAxWMzQhdbus+3QjWGAEH15kY+nWkIuF0u4oUFcl/GFQv9T4GIGc7ur3QhuuTfizX201NFxw0AvqudNoOUFp1yPLT4cY8hdSaCy4k7g2VwYCrClF8tQ1SlIQRw/a6AfSiFpblNVW/O6ZP4VET33OHY60cgcVMOeyYRi5wvDoWLa//uHH62TULpdKe0TypUhJEDV4sT1jBn/K0EfBG2tPeIw6qmo2lmDNuET+Jyy0msJqt X2pEZNx9 0uBMzUCL+t5NnXPY85QK6MKhWsjnT5inaFkyVMcI01Gj/oQDsMDkBYfvrgMjYoDEMSmEwB5e3RidySc+RCYbmxmlmSjOcHntx/+fMI+NPQFeoKsob8NyRVZ0ftRK7WvygYGej0YVcnRjK7/uDU4Tm21uh5ZTrxd6Qa92H1w9CWkL6OTK7Wo8UbmIXcab5Zemcy1VA2C6DYIzCx4RfFF8lH9AaNop/9wv32/BdSQnLv882dq4/2zR2Rz7b4/vq/5dGhxXqmUkj0k3g2IAu8IKGjh5iiURmHwAfD3y01UvCn6uq+IPLDFmHIVrRF00ZeDtWCxypxX2AaK/nMJM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.039728, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 16, 2025 at 7:14=E2=80=AFPM Michael Kelley wrote: > We had an earlier thread about INVLPGB/TLBSYNC in a VM [1]. It > turns out that Hyper-V in the Azure public cloud enables > INVLPGB/TLBSYNC in Confidential VMs (CVMs, which conform to the > Linux concept of a CoCo VM) running on AMD processors using SEV-SNP. > The CPUID instruction in a such a VM reports the enablement as > expected. The instructions are *not* enabled in general purpose VMs > running on the same AMD processors. The enablement is a natural > outgrowth of CoCo VM's wanting to be able to avoid a dependency on > the untrusted hypervisor to perform TLB flushes. What is this current dependency on the untrusted hypervisor? Is it just the PV TLB flushing optimization for preempted vCPUs? The normal x86 TLB flushing machinery waits for confirmation from the other vCPUs in smp_call_function_many_cond(), and the hypervisor shouldn't be able to fake that confirmation, right? Can you avoid this issue by disabling the PV TLB flushing optimization?