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 C0CE1C001DE for ; Thu, 13 Jul 2023 21:22:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A4908D0005; Thu, 13 Jul 2023 17:22:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 954898D0002; Thu, 13 Jul 2023 17:22:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81CCE8D0005; Thu, 13 Jul 2023 17:22:32 -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 6E9948D0002 for ; Thu, 13 Jul 2023 17:22:32 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3AB21C037E for ; Thu, 13 Jul 2023 21:22:32 +0000 (UTC) X-FDA: 81007862544.22.D90ED7B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id D45D41C0023 for ; Thu, 13 Jul 2023 21:22:28 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=bxbOZaBf; dmarc=none; spf=none (imf18.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=1689283350; a=rsa-sha256; cv=none; b=Tchoh9KTVKoRfyfbhkpq33U5Vow2rbQFpzu3XJFKBN3rIhb1eHsK6llCyI16o5MBmJKmz2 1j4Fa2ltzL5Frs0vQ+XZlVi8O0R4qzISguaSFmFahFIzIz4cH+EweIcS7bB3kdGQGlJiLy 6YeEXjK1YfRWZ1CghmZioBU69oXH47Y= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=bxbOZaBf; dmarc=none; spf=none (imf18.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=1689283350; 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=fxcF2LxM1o1X1zKtJxvwKJctPKOxt8kJ6pn0SPqkKNk=; b=HYPGiX+ELrCSk9T2393XIpE/fKoWtEBn7EeAl9NM59ot1tex9zy+nHqrXau/AdSlzBkX7P fOHyiizEt+cOaHxgGU6Y970F58LtgkEvB1UueceZs56BKtSOymHTJ8MpuHuorDcQuqhUsV oIHsZmQyoA2dYlrumou8atgF2fpVdIg= 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=fxcF2LxM1o1X1zKtJxvwKJctPKOxt8kJ6pn0SPqkKNk=; b=bxbOZaBfewQCzYAp/0OvSpKnk7 IHH2kLe95oKbphdIW/l/btaONo6dfsstnFOBdXvKLUf475O71ULPmAO51FRcsMKLWeLbBUDcEr8VK YpZo9rEsPImdJl+F/OnVbNJZsc7vkH5QFfLdPjo5LBazLDaMfMFKeO5cYtmbfjDDuP3/X9CADyOzc Hx1HWHSIhwcpjYqUl2jh0q/+CYaf8luyCaIPIQ4cyH2KYwV9h0+qz3SIHfaqZNEizFe3L4T55CYyr 2/scqQiv/a5AZBn3iVNDFqTV/xIPSwWAiZL5OVkRwRf2wDYMwYKItGOQnhmC2AGEs1PL2hAkS4B7O dYvyOjlw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qK3lV-000RuB-Jj; Thu, 13 Jul 2023 21:22:21 +0000 Date: Thu, 13 Jul 2023 22:22:21 +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> <75932f85-67c7-8065-9fa0-77d76db19e7b@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75932f85-67c7-8065-9fa0-77d76db19e7b@linux.ibm.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D45D41C0023 X-Stat-Signature: ujmb8umi6th48g6qjmatwd3z5gncuss4 X-HE-Tag: 1689283348-965291 X-HE-Meta: U2FsdGVkX1/3oEADHz5HXMkWwTQ0G4hIGWpI6vhCTQs/wyQ6hkEIIwOiWYuDbJk4yVZaIdU+/xDkMhKKPFDXL84ba154u6TxyzWMevAsfwC+iUJT6uu2sGNy+c4AskdZU41u7iVkoLdhuWGyj2B66NfTSUv8Gm4p5OEeI+28FHL2+gbewhGb1O7AkefWaMBb7hGes3t9lQT1mVkbZNSbAv4Va8/G5hC13y0rhPa+hk8GyC9hsNLcxwQB8OauWYWtnceYjzvd9SzJQVaABfdZ6oU342HHIg1RIOSfyey12htshAm0EHOh4OEqSvKcUnL5lsjhVpD4kUv9uMbEJH0/XbnyAdpADMcWU8ma2Bt6eAzDV9uFfUd/kUspzpPMDWOtXyA8idLrWYJmZdd2ev+sSVGWK1elEFmRwsf8LrqcFGgpo15sKMgbxlzNH36oKR13kt82h/STBtbewxcKRci86rVI1p632+mRgmx434DJSZZMHzEXLKVCJNejE5BwMjCKAMI/lL0up8tpXRVGg6sHHPeyMMIYXwDhbQoR+lliLks2dT1wIjv4aWGTFEpUYpaNvmuUGPpvybjqeCcAIFr+E74i5jrCu/RZK67pfulYgOny0WUteB2EVRdmvy0/4TdgtW/tK/ygiUtLHp7Ed2Olypnbn6uyujb/l6HaY2tfF0lvJKL051ibV5AXsuRXyseaKdlukdM4Dkum+01V4cLtDGH2imfUCS38rCzE8SzVsnLaoLDjMLXMkKxTqI2IL6IPGQ99/iYWJXLGueav9UR0RcawZAACO4h1BgIO3yY5ebF7B6g+jqJRarXgJYxWueXqVEqd4U5goQcDpBbwHz/fqdvNxFZ6PRJGesLr7xCNdk94xtaA1fXVMvP+8pETH/0oz+dcpmoUyjQlP51+Wpyhqn03nv+1uportApSLu8IADJ/bxeufnIBGgMNgvcT2e0sVFu1TjN5lL16s7t30FO rMpVFL1l SFM5F3EqScockTp/QFOoKAQxaxmWXzoi38DgnO7cVUPwX3/OzXXyeP/M2kL2IWkfXGqBSobyLpIb48tUCVY6kJ08iHBlWT3MMllcyccW3tpVa9arniZBEtqKqSfwuenm5a899MJOhYDdUhtE= 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 10:27:21PM +0200, Christian Borntraeger wrote: > > > 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? If that's a stupid question, you're going to find the answer utterly moronic ... Yes, we have split_folio() today. However, it can fail if somebody else has a reference to it, and if it does succeed, we don't really have a join_folio() operation (we have khugepaged which walks around looking for small folios it can replace with large folios, but that's not really what you want). In the MM of, let's say, 2025, I do intend to support what we might call a hole in a folio, precisely for hwpoison and it's beginning to sound a bit like it might work for you too. So you'd do something like ... Allocate a 256MB folio for your VM (probably one of many allocations you'd do to give your VM some memory). That sets 65536 page pointers to the same value. Then you "secure" all 256MB of it so the VM can use it all. Then the VM wants the host to read/write a 16kB chunk of that, so you allocate a "struct insecure_mem" and set four of the page pointers to point to that instead (it probably contains a copy of the original page pointer). We'd mark the folio as containing a hole so that the MM knows something unusual is going on. When you're done reading/writing the memory, you re-secure it, set the page pointers back to point to the original folio and free the struct insecure_mem. Would something like that work for you? Details TBD, of course.