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 CACDBC001DF for ; Thu, 13 Jul 2023 13:42:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E7256B0071; Thu, 13 Jul 2023 09:42:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3490C6B0072; Thu, 13 Jul 2023 09:42:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C3A390000B; Thu, 13 Jul 2023 09:42:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0831A6B0071 for ; Thu, 13 Jul 2023 09:42:36 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C6CD81C8230 for ; Thu, 13 Jul 2023 13:42:35 +0000 (UTC) X-FDA: 81006703470.09.D662CA0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id A1CE440020 for ; Thu, 13 Jul 2023 13:42:32 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xpm1APX1; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689255754; 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=eqRFjEfnQpKX3SCwpqVqk5MwPZ2HabqrXxJtbeOAy2Y=; b=4ZT1qk8HUmDcsKuccGArlRg9CqSnSVBxsIOkHw6SgYty+AyW92kVjzVvyUHaiBTwNJFxmR HYYo2aOOiZpF435EYAvCBF/Y2zdARjnrd0/Z2IcB/443fXgiJFwl/LOr8RwQ5dL4njKf4N 9gU1RQdhuDpxmwZBuuObyAlq8wO5hNc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689255754; a=rsa-sha256; cv=none; b=0ZGHTPqhoLhaTsSXm9A7D780mNJ9IRd+UYQ1zIf3i264pBMqnKsqtDmSMxYfk6Oii4ubsA j5eUIOV2mvUFM1ivVNqC3vl01pJngcRALbz/s8EatkO+T2l9wuCusidaEnuCDpuUzotjvI X7lgUqrlYzSHDxhSl+PUd6lD91B8O58= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xpm1APX1; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=eqRFjEfnQpKX3SCwpqVqk5MwPZ2HabqrXxJtbeOAy2Y=; b=Xpm1APX1flTFZG414QOtZyFKnZ XZBeRsaIEzyZfvFraA3stqUA2/UbL54AdKEFB+YFck5dODAOwA4k41eWWwLWsgZwoL1ESKsTR+JEB qPXiqSPVl4SVXOItL3fULoS6vqFOJRZkbdE2j9PPZ9qSq5PDb1pocBH6M6GYG3ZDPueKcKm/8/uPg lOGhsoeZM+ARDzp4/K+xXoJlYN9P3BMDpvKX5OnSNFOFq8PDZNz4Zc2ZO1YrEtObG2IUwAVSYIYXJ g43md3NOFX+J50BWHA43iAphI20mVnWgzi+bR/i913Yh0j0WnfUcmaRqX2QPr7bvlBolFXHd79J4X rjzKr0XA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qJwaQ-000Bur-DA; Thu, 13 Jul 2023 13:42:26 +0000 Date: Thu, 13 Jul 2023 14:42:26 +0100 From: Matthew Wilcox To: Christian Borntraeger Cc: Andrew Morton , Claudio Imbrenda , 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> <56ca93af-67dc-9d10-d27e-00c8d7c20f1b@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56ca93af-67dc-9d10-d27e-00c8d7c20f1b@linux.ibm.com> X-Rspamd-Queue-Id: A1CE440020 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: fjwmu8hxazy58m56tkokw7nuqgj955g1 X-HE-Tag: 1689255752-502724 X-HE-Meta: U2FsdGVkX19ygqAaA/8eYneylWDskiTBfIm295Lm+1WMBYIep122m26QOjmWVKw2r/hrg1vmhhfQqLLYDsSD5gUNbJQyQZKOzEp895QWzYW+6yfxc9LPGd9Dc4gXGCR9Do2iXZrzKTixwA/3CUV6rDPn4FvdxiyBSNiB7aayjnnFsu1VH9pkpFhk7DAFUTdBTglvfVEW2fsb8eggf76FTCkiELjE6FM8gt7ZX4ahvk+QeUxl+YG5o7rJyuJrrjY10DXGuAblPq/Krapw3pqJMaSuu80ITobXHygdvKYXKxVJ8tADPBmVTtH3N3nH3ukkoG73w+1Tkd4l9v5ucbdcbdEwCqM+LtytZWJtLPrj7YuuywafDTJTWo0zvEwHvgN6H0SjqcfNdumkBnwDPRVhSphYoA3kbLGHx36ggNjHXuBMMjX02jygIdr7gV5BHnIbccHhYRxDkgy5JKcDXjuCPEodT2b4IZAYILssnEUHjWWpWYGAI0aUHu1TBdYSbkncnG3gGENTbAlKFYx64vFRPseD3NcuUzGWXGOoUEL7pXtqjYHmH/XFr8ZKkTHWTyxLiPSw6bx2Oqb6D4TUN4URBwn5JolCGMr8FVu6oApVECtCk4ofHv1dqq6ZuloT2PWw2GsQLF7Z+PldM+b3j2cgPbqHktXbBUWGfwOiaRsYVG4132y4iXnF3ynyKQ7V6oH4zHWcRliGXFHTcHmATXEg/JAwn/GrrTE5EzJd7R+EdUSZ1sre6dvQ4cVrMaN3d4MGSfcRA3f+wATCnYJjx400RoL6fDmfgm9+mVLHHWfawNFjlUONzd9Ek6BMfIfwYhRf8zX3WoHzwr3t+4fQsVAFkmGDEw035SNs6kPJuBgQavX1i/JRCPzv9UUCl87Z9M38jvrPZdADx/2bdlKQHd0/PLa4Hgi3SHIyCEamaw4Y3bgQyOu/cKedo/+fO/h+gGtI62znf/+10TvzeUr8e9E TxuJd9ln gdEU7HJnox4m9iw9l3LBFnbKz9mIG7B2XHwR4e6j56IUUAO7Q5YH0HDmUYJm0wkZawuGQ28GO7v2/ELGA2heKnUvCNu6NvwYi/r3GvGj5sCdqAbg8wpwOOmtdH79vARlWJg5JilA/DVJy70Q= 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 Thu, Jul 13, 2023 at 12:42:44PM +0200, Christian Borntraeger wrote: > > > Am 11.07.23 um 14:36 schrieb Matthew Wilcox: > > On Tue, Jul 11, 2023 at 11:07:06AM +0200, Christian Borntraeger wrote: > > > Am 10.07.23 um 22:43 schrieb Matthew Wilcox (Oracle): > > > > This patchset changes the API used by the MM to set up page table entries. > > > > The four APIs are: > > > > set_ptes(mm, addr, ptep, pte, nr) > > > > update_mmu_cache_range(vma, addr, ptep, nr) > > > > flush_dcache_folio(folio) > > > > flush_icache_pages(vma, page, nr) > > > > > > > > flush_dcache_folio() isn't technically new, but no architecture > > > > implemented it, so I've done that for them. The old APIs remain around > > > > but are mostly implemented by calling the new interfaces. > > > > > > > > The new APIs are based around setting up N page table entries at once. > > > > The N entries belong to the same PMD, the same folio and the same VMA, > > > > so ptep++ is a legitimate operation, and locking is taken care of for > > > > you. Some architectures can do a better job of it than just a loop, > > > > but I have hesitated to make too deep a change to architectures I don't > > > > understand well. > > > > > > > > One thing I have changed in every architecture is that PG_arch_1 is now a > > > > per-folio bit instead of a per-page bit. This was something that would > > > > have to happen eventually, and it makes sense to do it now rather than > > > > iterate over every page involved in a cache flush and figure out if it > > > > needs to happen. > > > > > > 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 > > need a new design. s390 seems to do a lot of unusual things. I wish > > you'd talk to the rest of us more. > > I understand you point from a logical point of view, but a 4k page frame > is also a hardware defined memory region. And I think not only for us. > How do you want to implement hardware poisoning for example? > Marking the whole folio with PG_hwpoison seems wrong. For hardware poison, we can't use the page for any other purpose any more. So one of the 16 types of pointer is for hardware poison. That doesn't seem like it's a solution that could work for secure/insecure pages? But what I'm really wondering is why you need to transition pages between secure/insecure on a 4kB boundary. What's the downside to doing it on a 16kB or 64kB boundary, or whatever size has been allocated?