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 D8656C0015E for ; Thu, 13 Jul 2023 20:43:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08BFC8D0003; Thu, 13 Jul 2023 16:43:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03BA28D0002; Thu, 13 Jul 2023 16:43:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1E018D0003; Thu, 13 Jul 2023 16:43:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CF8008D0002 for ; Thu, 13 Jul 2023 16:43:25 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 95CEEB05CC for ; Thu, 13 Jul 2023 20:43:25 +0000 (UTC) X-FDA: 81007763970.10.6CD03D3 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf15.hostedemail.com (Postfix) with ESMTP id 0A06AA0013 for ; Thu, 13 Jul 2023 20:43:22 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=W7jUpo7X; spf=pass (imf15.hostedemail.com: domain of borntraeger@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=borntraeger@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689281003; 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=772T/pNvtTeSekLPdcFDuGm+FrrGOncjPpcPiRxQAsA=; b=dK8x3lHuXFoYS8GNLV7Xe8bGBPbZOz9cyN4JdyZjkbEnc09ALLDHH8OkWdbqUtaOGbPdO2 TsOvZvCy0rlGYaWlTFifmq0jU6IaVf/wCyk55KxtGGJWVRL5at4I5LDXH3bNBOzrqzPPHr Zt0Qgh1KdSovoxSlNSl2xd69O3yQGl0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689281003; a=rsa-sha256; cv=none; b=8FxN7qS5fO5/6d3R1VQusZzs3puVyxNtmBDAC+mcZFGw0+9hY/x+uR2krnDTDuoQ3pUP+R CxQNdgBVj96XWnM8M45RasDLCvX/USonGoudUZjX6wVT13RjsfpFNVrOepqt+LwKkaru1j 9slesr6XyA1/yZPVFkNSJ8nxwRa6L8c= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=W7jUpo7X; spf=pass (imf15.hostedemail.com: domain of borntraeger@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=borntraeger@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36DKHBxx017705; Thu, 13 Jul 2023 20:43:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=772T/pNvtTeSekLPdcFDuGm+FrrGOncjPpcPiRxQAsA=; b=W7jUpo7X+Vp1Op9klgbXzcdrpPz8PRd1CqWFJWf18U0QXV7NDECZDBS1xrSRpE6FaIgT 4DJw2C3hWfyPAbeIV8U7oQ46f6wv1kQ5ZBqntgt86s6MuAAszFYwgHTDhTx6wKQrgQNZ NO86pJgJVgZdAEHpldzvNJV3zPELmb7lcfr+JMmgn51VSZA9RohLaa9zZMKKODWEpUsP 2RexgKtXRdsRVRrW+CUWXgNxZJJZEH2+FSdJPgFmNAGSHjQf5/J+A5Y3MY018ambKH2y szcaUGP1D4OJr77hBdhgETo+f6KRnGmu3cQKbjTotg63/YgheNat6Gy7yurgvfiu3DZk 7Q== Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rtr5r0ss2-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Jul 2023 20:43:17 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 36DInN4F001168; Thu, 13 Jul 2023 20:27:26 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3rtpvur4tc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Jul 2023 20:27:26 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36DKRNcm42336770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Jul 2023 20:27:23 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4215720049; Thu, 13 Jul 2023 20:27:23 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B359220043; Thu, 13 Jul 2023 20:27:22 +0000 (GMT) Received: from [9.171.17.117] (unknown [9.171.17.117]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 13 Jul 2023 20:27:22 +0000 (GMT) Message-ID: <75932f85-67c7-8065-9fa0-77d76db19e7b@linux.ibm.com> Date: Thu, 13 Jul 2023 22:27:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v5 00/38] New page table range API To: Matthew Wilcox Cc: Andrew Morton , Claudio Imbrenda , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Gerald Schaefer , linux-s390 References: <20230710204339.3554919-1-willy@infradead.org> <8cfc3eef-e387-88e1-1006-2d7d97a09213@linux.ibm.com> <56ca93af-67dc-9d10-d27e-00c8d7c20f1b@linux.ibm.com> Content-Language: en-US From: Christian Borntraeger In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: hBhU07KTJ-nQvi3vo9XvqfWV1hZipSMI X-Proofpoint-ORIG-GUID: hBhU07KTJ-nQvi3vo9XvqfWV1hZipSMI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-13_08,2023-07-13_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 impostorscore=0 mlxscore=0 mlxlogscore=705 lowpriorityscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 spamscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307130182 X-Rspamd-Queue-Id: 0A06AA0013 X-Rspam-User: X-Stat-Signature: pjfjhnbyi4whjhtq3ztby338tbapheuy X-Rspamd-Server: rspam03 X-HE-Tag: 1689281002-936195 X-HE-Meta: U2FsdGVkX1/YV0jEYilDtQAUwis9kIItKQk4390AyqfB3aaYhYcaI9VnoUti3sD0+5MlgLi4ZgG5E9jEKpva3S0A8UDEawxUWGmjEfXfIUnFl3sWAxOO5L92dVk+CoW5BKe0uTcO8mKdk2pkFvfg6aexnOrz3ePMeB8OVbWYRQ5RjMyCL0Kb7Me17vZqNjsAneXXRm0zISnJ3cjX17LB8tcXJst5fE0yi1M3lzfc8cDrJkdQE/O0m/5Ttj+kwCf3P8U+23kOd8lHbzlo8QxY/6YHEOPu616ofoucBEvBoiA0yTtU4qhF89dKkznw2+mCWSfUIEQczhxpoe1RMnUkPF0SxdENh+zrWDesH+v2KCFBSp826bxDqQbPjim1be7eqsHfkd62jnHkSJa3znKOkmt4UIYK9ZXCLjzOjvs54fFHPP3GxR/zjWgTRQnV8sgvUyilripFbqxU4mZAdBM5OT6o7lpDQkQ0fpBwsff13O1lpBF6seFtvu83M9Dtez1up3XPK0/2nrpJLZxQill6mPu3Y9Q64YCGlmhBh2GB5QavVI4UpIq1sdgusK4bm3Jb6FYhp3eo0fen2diiyZWX9Bhqk3/SiZBMkK+kLgqkSkA+lr1tVA9q0EhZktjZH94z3pPujsKaaZfE9ZMb9m1p2A7tAgVPgmnKur+XtmG6zNFWUKm9XEHEs1L65ioJqtgZCmslPPjWcdbJGLJzNA0j5EidY6yQ4ol+KdO9QTfJtsaxH+uIgz5XCyUmlVSFxP6bifcHLK7OJQMGM+dyexxqFNm8gIgC9yBRqfr4yFGoY9WFFB3yMcSjVzs/lIr6E2REtnWvTD7uCgeoqEt1CVBYPSQeFGJ4okfA9GtXA5NYkypVGduuujpri6YmZl+8jn48ZFlF4d+uwYCKk00dT577BMkieJ7QHP3p9WU4I2tYGpHjuseRgiGWHq5UyObCox1YAeXJgOikwgn9IzLKQef 3KLkDgl/ gLALdl7jmVeqb7kne8kZofYwA0J+t5Whq98GdTwylNAUD2AOuI9Qi35uPnIWTdUv42NopFhs9BhBJ9U6STPloVdYHF3wEEfrMH258Ha3hs02El9NveaEL++2UI9TXBD2Kv960nveiMjPxaqDBdjG1PiHn9M8MYBXjZn5RajD0z2BZencsa2nfYVjT/6OxcPd9k1AMdsxiqYfDDtjZuqD2E4rEwSrY6+SCTVEh 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: Am 13.07.23 um 15:42 schrieb Matthew Wilcox: > 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? The export and import for more pages will be more expensive, but I assume that we would then also use the larger chunks (e.g. for paging). The more interesting problem is that the guest can make a page shared/non-shared on a 4kb granularity. Stupid question: can folios be split into folio,single page,folio when needed?