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 DD1CBEB64D9 for ; Wed, 12 Jul 2023 05:29:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C4ED6B0071; Wed, 12 Jul 2023 01:29:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24F066B0072; Wed, 12 Jul 2023 01:29:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 117296B0075; Wed, 12 Jul 2023 01:29:31 -0400 (EDT) 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 F2A656B0071 for ; Wed, 12 Jul 2023 01:29:30 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C38AF140509 for ; Wed, 12 Jul 2023 05:29:30 +0000 (UTC) X-FDA: 81001832100.26.BD56ECF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id 7F6B11C0002 for ; Wed, 12 Jul 2023 05:29:27 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pu63hKu+; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689139769; 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=qkUipoh9LzckasQjFT3oT/cjBw23ZeCHvwm10bQ21tI=; b=qRzm+L8fFXxKmbSGZGPjNUHSYvJaqabbBQut7oR6mPI5qlYPeRZsi4Tzi3uo09YA05L8or UknSqBLlaxTp5WRrg6709PRmQRcqpjFGGAj2fUYBQI0PD0CZRTaZzT+mK6nSvkqf4MS08c 9ufR+OquoPMLBJM182zbhXanL97uJCA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pu63hKu+; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689139769; a=rsa-sha256; cv=none; b=dmDl9eD64gAv1nQWmK7JVxpKNDeNUWSj6KadHlnxHNJnyfljoVG+PcQv5fBieRBCl69mt1 at4SYr7mbQxIoOdbaZookD1ffpwQLhCrpXXpK7vV1ijF9J6jTFVxent7/BDj//5ZdJIdlF ZPJTV3qMZg3EwcoUapg58G1Qm7R8BHw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=qkUipoh9LzckasQjFT3oT/cjBw23ZeCHvwm10bQ21tI=; b=pu63hKu+Y6EW+pxvwVAsG7hhWC GMMHP45auERXQ9P6kTrwFsw4uf5OompiG0bnM5muQ7WRBhb1ieo5xuw7jUN/T8j874KXD8i4Ph4Oa igN4TK0OjBRVUuSu5FweVlmBI0cf9iOJN6DSxgxiwIi13BSnTmCDXEspuZx4umFBJ5hyy+qND63yi nAwbvEHE8h0JVZSe3gWBfNFoTdJ1Y1RbvUSNZ/R3qRBxiTzNy4NNhfu9sXeKYzrqy7zoGOgCB0AOb 4iUqVmKlkGEMNC4FGJtBeJ9QQRYJas9FLvUmH18sF2Xn/lhNo6Ge0mR+0RM0itbezYj4LCM6PXNDK 9XmPq/8w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qJSPh-00GNN6-7t; Wed, 12 Jul 2023 05:29:21 +0000 Date: Wed, 12 Jul 2023 06:29:21 +0100 From: Matthew Wilcox To: Claudio Imbrenda Cc: Christian Borntraeger , Andrew Morton , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Gerald Schaefer , linux-s390 Subject: Re: [PATCH v5 00/38] New page table range API Message-ID: References: <20230710204339.3554919-1-willy@infradead.org> <8cfc3eef-e387-88e1-1006-2d7d97a09213@linux.ibm.com> <20230711172440.77504856@p-imbrenda> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230711172440.77504856@p-imbrenda> X-Rspamd-Queue-Id: 7F6B11C0002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wcstmkwhw61z17f6if5p3ef4pb1h7jc7 X-HE-Tag: 1689139767-600589 X-HE-Meta: U2FsdGVkX182xQF4t5JpXb31SvGVgVAKMVGsW+zg1GeNN25+Ilb2Nnc9e4dp2A3p2qjVCV5Wf6N5ZWnKMLcfNSHRZvuwrSioxMRdRZCRCG4tnf/WG478CY6jD4/7Ut8D57vBiga+svSZOa2vJCLJ2uwsO9DYq80zTjEP8udyaD7uFcI1z99itqOopuA51E3sw7/uL+9YT1FHvXBjw6Xm1uqoVlqh+jnke4HkaEqvhjfIWw6PdJYwzhrLJIigwZSWPrpeokkUE+OlK5H6RnLbrLjgryIKX917MF8YY+8huBG9G3JbGRwYmoz2FzVosO1kI7f18KaAuyzz5yXTBGBAUwj8RMN0D11fmcpQoGN3WTIWtKsdJuP40CIPjTXd37V5I+nyvoJs2h4pTjANpuwBnekt5EKh2IXpsValTwuQ5Mu1X7/vj8HJBI2FYe21C9k6dFHej86eGFwAMViCtluHfk/1rSiQ/0pqxG21uDq3ejFQ+3/arrHZH962mhq9UQ7I5Xj3P2cy+oGh4/Sp6N0L/bvjrU6TS1yphLIFuk+6fOHNExa0wy7Z7cTFyO3BTPBm/Wazsor1gaK5y0bO7r0KLzfwjAvbDt19dRpOQzFVUXps7Q3UA7eN6tsS/nO97aC53neV6cpa5cuQ/tpDdRuODqbpOJ7OKGxLaa3oRpY/XFQKdzE3UYs4CWhsj69sCgdjJPmj45WfLfvL3QJsivsn96DM2/FiZjIsbc5gPdLukJzeEm5mQKwb1mEDbYAQCmrBs6dHN1YPVIazQT6Kk7FbTTxWpyQS2LM2L7BieSi7aZ0uhMwzY+huo0uVbV1owokLwcV+0dTm0145b9//a0Oq8xFaOzp4n+pZb+Xjag/UvSCn6xJkiT2Jqv6N9SaRX64/PIC6OkMqbWI/7Rgguxf/f1VtrIsnHmpqMD77t/f16+qgn+GWNnO9tID9tmB+vicM0XuyGMdGCX0n5/c6q4W VENypKJg ObMOzHBWrXp7E8s8p3PJPxOd1PtL0eL10NxxCNQftayOkCeF+lY10gDbWRI/7ftaEvz/Dhc/uYXG9CwYA88B4vp8FL89UMbY5nsj9VEhkeWeUUM+5iKCMD35xcfpcBD5fYvDy9S82E1SUktW9mfQAvfORN/1OgTUPUdf4VkASx2bqYnbr4CV//+rAM3c9IeN920E1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jul 11, 2023 at 05:24:40PM +0200, Claudio Imbrenda wrote: > On Tue, 11 Jul 2023 13:36:27 +0100 > Matthew Wilcox wrote: > > > I think we do use PG_arch_1 on s390 for our secure page handling and > > > making this perf folio instead of physical page really seems wrong > > > and it probably breaks this code. > > > > Per-page flags are going away in the next few years, so you're going to > > For each 4k physical page frame, we need to keep track whether it is > secure or not. Do you? Wouldn't it make more sense to track that per allocation instead of per page? ie if we allocate a 16kB anon folio for a VMA, don't you want the entire folio to be marked as secure vs insecure? I don't really know what secure means in this context. I think it has something to do with which of the VM or the hypervisor can access it, but it feels like something new that I've never had properly explained to me. > A bit in struct page seems the most logical choice. If that's not > possible anymore, how would you propose we should do? The plan is to shrink struct page down to a single pointer (which includes a few tag bits to say what type that pointer is -- a page table, anon mem, file mem, slab, etc). So there won't be any bits available for something like "secure or not". You could use a side structure if you really need to keep track on a per page basis.