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 66AFAC282EC for ; Tue, 18 Mar 2025 13:03:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0ADD1280004; Tue, 18 Mar 2025 09:03:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05E28280001; Tue, 18 Mar 2025 09:03:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6C1A280004; Tue, 18 Mar 2025 09:03:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C7F9B280001 for ; Tue, 18 Mar 2025 09:03:09 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 201C6ABA93 for ; Tue, 18 Mar 2025 13:03:10 +0000 (UTC) X-FDA: 83234687340.09.CCCC82F Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) by imf03.hostedemail.com (Postfix) with ESMTP id 3D6872000F for ; Tue, 18 Mar 2025 13:03:08 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=If+tQsxW; spf=pass (imf03.hostedemail.com: domain of 3Cm_ZZwgKCJM6xz79xAy3BB381.zB985AHK-997Ixz7.BE3@flex--jackmanb.bounces.google.com designates 209.85.128.73 as permitted sender) smtp.mailfrom=3Cm_ZZwgKCJM6xz79xAy3BB381.zB985AHK-997Ixz7.BE3@flex--jackmanb.bounces.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=1742302988; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=whP3Ztar/RkUapRVfDAPzBt4fOO+FCwNAyDQSaMiseQ=; b=aJWfhTchCFeZxWXgkgEUczU1PdT9c2J761gKc7znCATkBv+tRawdQGIPtdNL08xLiun3Nv 79ZrYHedGrDt6G14pRfMNJsM1D4JOrcPQEz2S2eSIHiCyjhsXY23PRp9yXuPBmlup7zku5 PRV3JE/eUOiheVHgSxCz5KZKijX58Yk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=If+tQsxW; spf=pass (imf03.hostedemail.com: domain of 3Cm_ZZwgKCJM6xz79xAy3BB381.zB985AHK-997Ixz7.BE3@flex--jackmanb.bounces.google.com designates 209.85.128.73 as permitted sender) smtp.mailfrom=3Cm_ZZwgKCJM6xz79xAy3BB381.zB985AHK-997Ixz7.BE3@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742302988; a=rsa-sha256; cv=none; b=d3R5moCmCD+97r4O2NQFGzASp35TRsq6N5aB7O/X88hWkdXSqIalIbHryFsZwPGmo0av+B rgqfLZnFLikEx1h3kdYmptT568RuwPgSoVuUdwJ8B1sTYnkTv53i21qJh2duTr0UvG/CPO Fqi7yAKP6LkAT6URoM/o2xzb1TpCD+Y= Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-4394c489babso15984375e9.1 for ; Tue, 18 Mar 2025 06:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742302987; x=1742907787; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=whP3Ztar/RkUapRVfDAPzBt4fOO+FCwNAyDQSaMiseQ=; b=If+tQsxWSAa5S2m4ZqZy4UAIRUbmlTTmWIIu/j/hCUFfT3D5OKfPl04OUTtlD8OJJA R0/xBkF9qA8LCx4YMJBOZg9WHo0bJh9uCHwZr9qVE/C2h0nTIaT41tbyOwSCLf2icTCs hFf1btEZ5ZHGtXGaYxQ7hJCzTtDv+SLZLymzN8T64ZUwT0NlLDb5vqjLP6NL41KnDbh6 9SoNyXMeljayVQ7n9d61CiMUrwHaJmnThSYXVEThiAa8UKe5QSevrcIt5GodWVW2ybtD 96zicm8IPqBlLKTsd/Sf0FnU211wlCOaZ5BmfVKF/VyPmL/pBZyp0WSaKpc4byBynPEC ZlIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742302987; x=1742907787; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=whP3Ztar/RkUapRVfDAPzBt4fOO+FCwNAyDQSaMiseQ=; b=WZ5phsIERQnpNl6V2EAtbYE2s/Tw0gQoQiByJF8bf80uWmmiOMlXIN6zI5qk5OKu1H Fdp+5NULbBX9RweM59ZK0MopCv/dRRzBXu1Yoh1PgZoW3sBA0zSjVF4fBb3sqbNv636O 9QuSahRxVQ0SISLSmwMtkUu9FcpUBRfyymrlqL0yJpsyM2LMiGzGzBayQSdqdkjS/5Ag agvDFdTDucwYifmuA3tqVfjF97tDQ6kw7h4th7vK0kYu7g9LisfIT/WrY1etXUs2DXci lbDkbja2/uhT0P+W2WY0UlVRBSkXTdLA8CAxPvvAV9gLChiLyeF0b1LLNi5PZtORUvTI 5CeQ== X-Forwarded-Encrypted: i=1; AJvYcCUr+abz880GhwDk5t1XUBlmLWap/nhWt5Qpc/Pz067NmGJPyd3Eg/Jn0M+iIIZffzJ8NWgiOoOhqA==@kvack.org X-Gm-Message-State: AOJu0YxZB+Qv4VDyv/aSVc0jV0FwVxTHT78oTftgHZ96kpIpntfJhfKd rRVAUQCxj4a3ztsVgaVgx42Xq/yPn0UHHcA9+fvWvX3F2c/AFkqFw/ueDFden7ejJmYTGQIGc+t x/wJ13M2sbw== X-Google-Smtp-Source: AGHT+IEo/v26Aru3DgRKudIcvvi5iVXlISbjRtcfMMClu/BOmgGyumhv1wki9aUCVQEAJDbjuPXzjomGr/lwuQ== X-Received: from wmbes18.prod.google.com ([2002:a05:600c:8112:b0:43b:c7e5:66e0]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:1da4:b0:43d:26e3:f2f6 with SMTP id 5b1f17b1804b1-43d3b950035mr23761825e9.5.1742302986910; Tue, 18 Mar 2025 06:03:06 -0700 (PDT) Date: Tue, 18 Mar 2025 13:03:05 +0000 In-Reply-To: <4ce0b11c-d2fd-4dff-b9db-30e50500ee83@google.com> Mime-Version: 1.0 References: <20250227120607.GPZ8BVL2762we1j3uE@fat_crate.local> <20250228084355.2061899-1-jackmanb@google.com> <20250314131419.GJZ9Qrq8scAtDyBUcg@fat_crate.local> <5aa114f7-3efb-4dab-8579-cb9af4abd3c0@google.com> <20250315123621.GCZ9V0RWGFapbQNL1w@fat_crate.local> <4ce0b11c-d2fd-4dff-b9db-30e50500ee83@google.com> X-Mailer: aerc 0.18.2 Message-ID: Subject: Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API From: Brendan Jackman To: Junaid Shahid , Borislav Petkov Cc: , , , , , , , , , Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 3D6872000F X-Rspamd-Server: rspam08 X-Stat-Signature: 3ja87ap8o77mifs6tz7k5qbc68jjbqqc X-HE-Tag: 1742302988-880512 X-HE-Meta: U2FsdGVkX1/4l4mJQp5AaW22Lesk5CzVmfJjREbR33lkNhd0957gffz2Gj9Izp3GchHpSPu7tqoosC/8MoLrvTfkKaRWOGlkEBSYZaTWwHOLXwyjKXFw1M9KaLBv+C+lzO68QLyyIglI/AxMJskGlW2t/Cv/tmqT3XAly2KU5n3+0reOSSAeOM1W2UEWL4GVWq53lQvoGZo5o5a6yaNS9sXEDFjh7KQb8AqTplFvOBfDu6KCRv5kZWSE3CGQqGJzVqWimdObHASgIei9GB9LBNeUSGWAgcf0M9rZWU9hxk7eO/Eb/SET7DODspMAv2jd7FrCh9fHnTkYFuvve3cUub7hmeAlVCiO3Sw1z2csQLTdgftXtyG0rFuz9wJsfNrAxqxk7zKnLJcpit6PSvlfNcWwZ2EiaK41ZLsfeeXePvowfa6QhmBrSE+NnA/MgWMVoJmAM74B7w2815f2vzJczQH3G0mj3sJaR2CgKJVuqK858k3A8/EJ4nf1/aCfdMiX7vVV3XmB2Ktc2OP+Jiz9PWM54nKAAd9EW8rfU170Yc5Q9jzMPhM2vbY5OkqL2CQLMW/WpS/JlDYmwWR013qAEYI57lVwvVf0lxuyE5kM0YYionuiDu05PSQn5d4/nBYwH6qYukUNi+cyqYPDiqsWZO8TDbDTjnE/daeshkP+nfc471kcSfT3ZkWdUdBNvicVzYnfrV1T/yDSfgGoDC9vl+/A08MyTT/JlTwigsXp3FWxnb6lYN+e5G676zlCL2hONDXq+Ns/tbharL3JsS/qFoTAaIIf6VjciupADQiKuSK0uLjGIbM36IZXf2YJqhb8c9HkWQ0sVJNUGBI0AgMr+6tsRAQlGvZkgRkdKYo5cMFQCvSWq/w9Z9dJWxdhmQEDpwbvv+wjiLLU76/2NHDr0HTbtcGOA8DpVzPTG/c68q3CWH1gsi8Vu7OPXa+LnD4rYnNhYPXusB+B9btlMjm wEBD5ox0 2onN2IYbDj9m8qKI4EoiF01z7HEgtKBvvfenVPxcJSOJzDR+ATdtPAygalW8gfmcXUMxA+9K2faAkIrCRdlIdo/nErv8Ykc1sCLYzeMK3urT0rDdzc/p3iAG96x+CZxpEfyat2MGZVMbRAsqZzaaL+6MEysje5a1Jm6dBKeVU5ERbLiHHCeQN29mRrUirIns8hfEGtEYnlV1+vZ2HQ+3to8i9tGgQwLKvg2N11Hl0K0tayaMoTpZj+atTwIHEyrL3xxoR71GZlqQD7Qqn/FcA2WdnzIoxwF8n/ASQ4YnqQetpXcgzMWzfPltp3LM9WYo8I4+XCmaUgd4VO5nMAJE9Ynuy+lMHkyFyAMQI7k7jIXl45eg8/6XKeXttKxiUXPBoMbAdAxNIPY8ELmothTLN0QJzhPUs/x5SNyWNLT1mTQWNu2twzn9FTYX2czFmUHqHzGrmiSQ/OtOIq4hp/JLV5Xmz2oT+boL2TiTHIv7A/KPU0qX7efvVTm10XhxPllDaukX/pOd2L5LIYtdV8fOxsn7PXCnSGRonMs6mFGu6fn0CDerCZoI4kYuEjWXBsR2iWaSU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000973, 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 Tue Mar 18, 2025 at 12:50 AM UTC, Junaid Shahid wrote: > On 3/17/25 4:40 AM, Brendan Jackman wrote: > > > > I don't understand having both asi_[un]lock() _and_ > > asi_{start,enter}_critical_region(). The only reason we need the > > critical section concept is for the purposes of the NMI glue code you > > mentioned in part 1, and that setup must happen before the switch into > > the restricted address space. > > > > Also, I don't think we want part 5 inside the asi_lock()->asi_unlock() > > region. That seems like the region betwen part 5 and 6, we are in the > > unrestricted address space, but the NMI entry code is still set up to > > return to the restricted address space on exception return. I think > > that would actually be harmless, but it doesn't achieve anything. > > > > The more I talk about it, the more convinced I am that the proper API > > should only have two elements, one that says "I'm about to run > > untrusted code" and one that says "I've finished running untrusted > > code". But... > > > >> 1. you can do empty calls to keep the interface balanced and easy to use > >> > >> 2. once you can remove asi_exit(), you should be able to replace all in-tree > >> users in one atomic change so that they're all switched to the new, > >> simplified interface > > > > Then what about if we did this: > > > > /* > > * Begin a region where ASI restricted address spaces _may_ be used. > > * > > * Preemption must be off throughout this region. > > */ > > static inline void asi_start(void) > > { > > /* > > * Cannot currently context switch in the restricted adddress > > * space. > > */ > > lockdep_assert_preemption_disabled(); > > I assume that this limitation is just for the initial version in this RFC, > right? Well I think we also wanna get ASI in-tree with this limitation, otherwise the initial series will be too big and complex. But yea, it's a temporary thing for sure. Maybe resolving that would be the highest-priority issue once ASI is merged. > But even in that case, I think this should be in asi_start_critical() > below, not asi_start(), since IIRC the KVM run loop does contain preemptible > code as well. And we would need an explicit asi_exit() in the context switch > code like we had in an earlier RFC. Oh. Yeah. In my proposal below I had totally forgotten we had asi_exit() in the context_switch() path (it is there in this patch). So we only need the asi_exit() in the KVM code in order to avoid actually hitting e.g. exit_to_user_mode() in the restricted address space. But... we can just put an asi_exit() there explicitly instead of dumping all this weirdness into the "core API" and the KVM codebase. So... I think all we really need is asi_start_critical() and asi_end_critical()? And make everything else happen as part of the normal functioning of the entry and context-switching logic. Am I forgetting something else?