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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 596E4C4345F for ; Thu, 25 Apr 2024 10:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:From: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pavuehBhFD4XSqBjPwm63OwoyxY3hORSd9pck5BwfXg=; b=ltBaBpbACp8rJz rAfkSkMuFHNTy/1//juapCsUvB0ZbwzoiAwkuX8FwOGbs6FrFVGGilD6lCUOKTOpemchkJEqlJtli 8uevNsPukTxOFdmqvYyYowIYS0Wovb/WIKJshBs2oqSPgPfhO84M/EAuYrBC8zBqBCWwmuumIYiYr Bn80p8eIfG1uwP0TiP6LLjPLHiDrH3Zsp93Mzv0+dfUupuR0WEXKp4m7SlzpmcIndn/zGQfYqEQ+0 CTcRcsgVSzpdaoj5AJFmtQZBKIGpT2unvDqkZH9/BVHPHk5w6whOLB1Xe+Shq4mFdcKKg7tptzUKA f6BBvwmHWdPg0W6w5Dow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzwU8-00000007rTt-2tfa; Thu, 25 Apr 2024 10:37:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzwU5-00000007rTD-3cTY for linux-arm-kernel@lists.infradead.org; Thu, 25 Apr 2024 10:37:47 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 18F6D1007; Thu, 25 Apr 2024 03:38:13 -0700 (PDT) Received: from [10.1.27.187] (unknown [10.1.27.187]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7467A3F64C; Thu, 25 Apr 2024 03:37:43 -0700 (PDT) Message-ID: Date: Thu, 25 Apr 2024 11:37:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] arm64/mm: Move PTE_PROT_NONE and PMD_PRESENT_INVALID Content-Language: en-GB From: Ryan Roberts To: David Hildenbrand , Catalin Marinas , Will Deacon , Joey Gouly , Ard Biesheuvel , Mark Rutland , Anshuman Khandual , Peter Xu , Mike Rapoport , Shivansh Vij Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20240424111017.3160195-1-ryan.roberts@arm.com> <20240424111017.3160195-2-ryan.roberts@arm.com> In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240425_033746_036321_AE570A0D X-CRM114-Status: GOOD ( 29.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gMjUvMDQvMjAyNCAxMToyOSwgUnlhbiBSb2JlcnRzIHdyb3RlOgo+IE9uIDI1LzA0LzIwMjQg MTA6MTYsIERhdmlkIEhpbGRlbmJyYW5kIHdyb3RlOgo+PiBPbiAyNC4wNC4yNCAxMzoxMCwgUnlh biBSb2JlcnRzIHdyb3RlOgo+Pj4gUHJldmlvdXNseSBQVEVfUFJPVF9OT05FIHdhcyBvY2N1cHlp bmcgYml0IDU4LCBvbmUgb2YgdGhlIGJpdHMgcmVzZXJ2ZWQKPj4+IGZvciBTVyB1c2Ugd2hlbiB0 aGUgUFRFIGlzIHZhbGlkLiBUaGlzIGlzIGEgd2FzdGUgb2YgdGhvc2UgcHJlY2lvdXMgU1cKPj4+ IGJpdHMgc2luY2UgUFRFX1BST1RfTk9ORSBjYW4gb25seSBldmVyIGJlIHNldCB3aGVuIHZhbGlk IGlzIGNsZWFyLgo+Pj4gSW5zdGVhZCBsZXQncyBvdmVybGF5IGl0IG9uIHdoYXQgd291bGQgYmUg YSBIVyBiaXQgaWYgdmFsaWQgd2FzIHNldC4KPj4+Cj4+PiBXZSBuZWVkIHRvIGJlIGNhcmVmdWwg YWJvdXQgd2hpY2ggSFcgYml0IHRvIGNob29zZSBzaW5jZSBzb21lIG9mIHRoZW0KPj4+IG11c3Qg YmUgcHJlc2VydmVkOyB3aGVuIHB0ZV9wcmVzZW50KCkgaXMgdHJ1ZSAoYXMgaXQgaXMgZm9yIGEK Pj4+IFBURV9QUk9UX05PTkUgcHRlKSwgaXQgaXMgbGVnaXRpbWF0ZSBmb3IgdGhlIGNvcmUgdG8g Y2FsbCB2YXJpb3VzCj4+PiBhY2Nlc3NvcnMsIGUuZy4gcHRlX2RpcnR5KCksIHB0ZV93cml0ZSgp IGV0Yy4gVGhlcmUgYXJlIGFsc28gc29tZQo+Pj4gYWNjZXNzb3JzIHRoYXQgYXJlIHByaXZhdGUg dG8gdGhlIGFyY2ggd2hpY2ggbXVzdCBjb250aW51ZSB0byBiZQo+Pj4gaG9ub3VyZWQsIGUuZy4g cHRlX3VzZXIoKSwgcHRlX3VzZXJfZXhlYygpIGV0Yy4KPj4+Cj4+PiBTbyB3ZSBjaG9vc2UgdG8g b3ZlcmxheSBQVEVfVVhOOyBUaGlzIGVmZmVjdGl2ZWx5IG1lYW5zIHRoYXQgd2hlbmV2ZXIgYQo+ Pj4gcHRlIGhhcyBQVEVfUFJPVF9OT05FIHNldCwgaXQgd2lsbCBhbHdheXMgcmVwb3J0IHB0ZV91 c2VyX2V4ZWMoKSA9PQo+Pj4gZmFsc2UsIHdoaWNoIGlzIG9idmlvdXNseSBhbHdheXMgY29ycmVj dC4KPj4+Cj4+PiBBcyBhIHJlc3VsdCBvZiB0aGlzIGNoYW5nZSwgd2UgbXVzdCBzaHVmZmxlIHRo ZSBsYXlvdXQgb2YgdGhlCj4+PiBhcmNoLXNwZWNpZmljIHN3YXAgcHRlIHNvIHRoYXQgUFRFX1BS T1RfTk9ORSBpcyBhbHdheXMgemVybyBhbmQgbm90Cj4+PiBvdmVybGFwcGluZyB3aXRoIGFueSBv dGhlciBmaWVsZC4gQXMgYSByZXN1bHQgb2YgdGhpcywgdGhlcmUgaXMgbm8gd2F5Cj4+PiB0byBr ZWVwIHRoZSBgdHlwZWAgZmllbGQgY29udGlndW91cyB3aXRob3V0IGNvbmZsaWN0aW5nIHdpdGgK Pj4+IFBNRF9QUkVTRU5UX0lOVkFMSUQgKGJpdCA1OSksIHdoaWNoIG11c3QgYWxzbyBiZSAwIGZv ciBhIHN3YXAgcHRlLiBTbwo+Pj4gbGV0J3MgbW92ZSBQTURfUFJFU0VOVF9JTlZBTElEIHRvIGJp dCA2MC4KPj4KPj4gQSBub3RlIHRoYXQgc29tZSBhcmNocyBzcGxpdC9yZS1jb21iaW5lIHR5cGUg YW5kL29yIG9mZnNldCwgdG8gbWFrZSB1c2Ugb2YgZXZlcnkKPj4gYml0IHBvc3NpYmxlIDopIEJ1 dCB0aGF0J3MgbW9zdGx5IHJlbGV2YW50IGZvciAzMmJpdC4KPj4KPj4gKGFuZCBhcyBsb25nIGFz IFBGTnMgY2FuIHN0aWxsIGZpdCBpbnRvIHRoZSBzd3Agb2Zmc2V0IGZvciBtaWdyYXRpb24gZW50 cmllcyBldGMuKQo+IAo+IFllYWgsIEkgY29uc2lkZXJlZCBzcGxpdHRpbmcgdGhlIHR5cGUgb3Ig b2Zmc2V0IGZpZWxkIHRvIGF2b2lkIG1vdmluZwo+IFBNRF9QUkVTRU5UX0lOVkFMSUQsIGJ1dCB0 aG91Z2h0IGl0IHdhcyBiZXR0ZXIgdG8gYXZvaWQgdGhlIGV4dHJhIG1hc2sgYW5kIHNoaWZ0LgoK QWxzbywgSU1ITyB3ZSBzaG91bGRuJ3QgcmVhbGx5IG5lZWQgdG8gcmVzZXJ2ZSBQTURfUFJFU0VO VF9JTlZBTElEIGZvciBzd2FwCnB0ZXM7IGl0IHdvdWxkIGJlIGNsZWFuZXIgdG8gaGF2ZSBvbmUg Yml0IHRoYXQgZGVmaW5lcyAicHJlc2VudCIgd2hlbiB2YWxpZCBpcwpjbGVhciAoc2ltaWxhciB0 byBQVEVfUFJPVF9OT05FIHRvZGF5KSB0aGVuIGFub3RoZXIgYml0IHdoaWNoIGlzIG9ubHkgZGVm aW5lZAp3aGVuICJwcmVzZW50ICYmICF2YWxpZCIgd2hpY2ggdGVsbHMgdXMgaWYgdGhpcyBpcyBQ VEVfUFJPVF9OT05FIG9yClBNRF9QUkVTRU5UX0lOVkFMSUQgKEkgZG9uJ3QgdGhpbmsgeW91IGNh biBldmVyIGhhdmUgYm90aCBhdCB0aGUgc2FtZSB0aW1lPykuCgpCdXQgdGhlcmUgaXMgYSBwcm9i bGVtIHdpdGggdGhpczogX19zcGxpdF9odWdlX3BtZF9sb2NrZWQoKSBjYWxscwpwbWRwX2ludmFs aWRhdGUoKSBmb3IgYSBwbWQgYmVmb3JlIGl0IGRldGVybWluZXMgdGhhdCBpdCBpcyBwbWRfcHJl c2VudCgpLiBTbwp0aGUgUE1EX1BSRVNFTlRfSU5WQUxJRCBjYW4gYmUgc2V0IGluIGEgc3dhcCBw dGUgdG9kYXkuIFRoYXQgZmVlbHMgd3JvbmcgdG8gbWUsCmJ1dCB3YXMgdHJ5aW5nIHRvIGF2b2lk IHRoZSB3aG9sZSB0aGluZyB1bnJhdmVsbGluZyBzbyBkaWRuJ3QgcGVyc3VlLgoKPiAKPj4KPj4+ Cj4+PiBJbiB0aGUgZW5kLCB0aGlzIGZyZWVzIHVwIGJpdCA1OCBmb3IgZnV0dXJlIHVzZSBhcyBh IHByb3BlciBTVyBiaXQgKGUuZy4KPj4+IHNvZnQtZGlydHkgb3IgdWZmZC13cCkuCj4+Cj4+IEkg d2FzIGJyaWVmbHkgY29uZnVzZWQgYWJvdXQgaG93IHlvdSB3b3VsZCB1c2UgdGhlc2UgYml0cyBh cyBTVyBiaXRzIGZvciBzd2FwCj4+IFBURXMgKHdoaWNoIHlvdSBjYW4ndCBhcyB0aGV5IG92ZXJs YXkgdGhlIHR5cGUpLiBTZWUgYmVsb3cgcmVnYXJkaW5nIGJpdCAzLgo+Pgo+PiBJIHdvdWxkIGhh dmUgc2FpZCBoZXJlICJwcm9wZXIgU1cgYml0IGZvciBwcmVzZW50IFBURXMiLgo+IAo+IFllczsg SSdsbCBjbGFyaWZ5IGluIHRoZSBuZXh0IHZlcnNpb24uCj4gCj4+Cj4+Pgo+Pj4gU2lnbmVkLW9m Zi1ieTogUnlhbiBSb2JlcnRzIDxyeWFuLnJvYmVydHNAYXJtLmNvbT4KPj4+IC0tLQo+Pj4gwqAg YXJjaC9hcm02NC9pbmNsdWRlL2FzbS9wZ3RhYmxlLXByb3QuaCB8wqAgNCArKy0tCj4+PiDCoCBh cmNoL2FybTY0L2luY2x1ZGUvYXNtL3BndGFibGUuaMKgwqDCoMKgwqAgfCAxNiArKysrKysrKyst LS0tLS0tCj4+PiDCoCAyIGZpbGVzIGNoYW5nZWQsIDExIGluc2VydGlvbnMoKyksIDkgZGVsZXRp b25zKC0pCj4+Pgo+Pj4gZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vcGd0YWJs ZS1wcm90LmgKPj4+IGIvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9wZ3RhYmxlLXByb3QuaAo+Pj4g aW5kZXggZGQ5ZWU2N2QxZDg3Li5lZjk1MmQ2OWZkMDQgMTAwNjQ0Cj4+PiAtLS0gYS9hcmNoL2Fy bTY0L2luY2x1ZGUvYXNtL3BndGFibGUtcHJvdC5oCj4+PiArKysgYi9hcmNoL2FybTY0L2luY2x1 ZGUvYXNtL3BndGFibGUtcHJvdC5oCj4+PiBAQCAtMTgsMTQgKzE4LDE0IEBACj4+PiDCoCAjZGVm aW5lIFBURV9ESVJUWcKgwqDCoMKgwqDCoMKgIChfQVQocHRldmFsX3QsIDEpIDw8IDU1KQo+Pj4g wqAgI2RlZmluZSBQVEVfU1BFQ0lBTMKgwqDCoMKgwqDCoMKgIChfQVQocHRldmFsX3QsIDEpIDw8 IDU2KQo+Pj4gwqAgI2RlZmluZSBQVEVfREVWTUFQwqDCoMKgwqDCoMKgwqAgKF9BVChwdGV2YWxf dCwgMSkgPDwgNTcpCj4+PiAtI2RlZmluZSBQVEVfUFJPVF9OT05FwqDCoMKgwqDCoMKgwqAgKF9B VChwdGV2YWxfdCwgMSkgPDwgNTgpIC8qIG9ubHkgd2hlbiAhUFRFX1ZBTElEICovCj4+PiArI2Rl ZmluZSBQVEVfUFJPVF9OT05FwqDCoMKgwqDCoMKgwqAgKFBURV9VWE4pwqDCoMKgwqDCoMKgwqDC oCAvKiBSZXVzZSBQVEVfVVhOOyBvbmx5IHdoZW4KPj4+ICFQVEVfVkFMSUQgKi8KPj4+IMKgIMKg IC8qCj4+PiDCoMKgICogVGhpcyBiaXQgaW5kaWNhdGVzIHRoYXQgdGhlIGVudHJ5IGlzIHByZXNl bnQgaS5lLiBwbWRfcGFnZSgpCj4+PiDCoMKgICogc3RpbGwgcG9pbnRzIHRvIGEgdmFsaWQgaHVn ZSBwYWdlIGluIG1lbW9yeSBldmVuIGlmIHRoZSBwbWQKPj4+IMKgwqAgKiBoYXMgYmVlbiBpbnZh bGlkYXRlZC4KPj4+IMKgwqAgKi8KPj4+IC0jZGVmaW5lIFBNRF9QUkVTRU5UX0lOVkFMSUTCoMKg wqAgKF9BVChwdGV2YWxfdCwgMSkgPDwgNTkpIC8qIG9ubHkgd2hlbgo+Pj4gIVBNRF9TRUNUX1ZB TElEICovCj4+PiArI2RlZmluZSBQTURfUFJFU0VOVF9JTlZBTElEwqDCoMKgIChfQVQocHRldmFs X3QsIDEpIDw8IDYwKSAvKiBvbmx5IHdoZW4KPj4+ICFQTURfU0VDVF9WQUxJRCAqLwo+Pj4gwqAg wqAgI2RlZmluZSBfUFJPVF9ERUZBVUxUwqDCoMKgwqDCoMKgwqAgKFBURV9UWVBFX1BBR0UgfCBQ VEVfQUYgfCBQVEVfU0hBUkVEKQo+Pj4gwqAgI2RlZmluZSBfUFJPVF9TRUNUX0RFRkFVTFTCoMKg wqAgKFBNRF9UWVBFX1NFQ1QgfCBQTURfU0VDVF9BRiB8IFBNRF9TRUNUX1MpCj4+PiBkaWZmIC0t Z2l0IGEvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9wZ3RhYmxlLmggYi9hcmNoL2FybTY0L2luY2x1 ZGUvYXNtL3BndGFibGUuaAo+Pj4gaW5kZXggYWZkZDU2ZDI2YWQ3Li4yM2FhYmZmNGZhNmYgMTAw NjQ0Cj4+PiAtLS0gYS9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL3BndGFibGUuaAo+Pj4gKysrIGIv YXJjaC9hcm02NC9pbmNsdWRlL2FzbS9wZ3RhYmxlLmgKPj4+IEBAIC0xMjQ4LDIwICsxMjQ4LDIy IEBAIHN0YXRpYyBpbmxpbmUgcG1kX3QgcG1kcF9lc3RhYmxpc2goc3RydWN0Cj4+PiB2bV9hcmVh X3N0cnVjdCAqdm1hLAo+Pj4gwqDCoCAqIEVuY29kZSBhbmQgZGVjb2RlIGEgc3dhcCBlbnRyeToK Pj4+IMKgwqAgKsKgwqDCoCBiaXRzIDAtMTrCoMKgwqAgcHJlc2VudCAobXVzdCBiZSB6ZXJvKQo+ Pj4gwqDCoCAqwqDCoMKgIGJpdHMgMjrCoMKgwqDCoMKgwqDCoCByZW1lbWJlciBQR19hbm9uX2V4 Y2x1c2l2ZQo+Pj4gLSAqwqDCoMKgIGJpdHMgMy03OsKgwqDCoCBzd2FwIHR5cGUKPj4+IC0gKsKg wqDCoCBiaXRzIDgtNTc6wqDCoMKgIHN3YXAgb2Zmc2V0Cj4+PiAtICrCoMKgwqAgYml0wqAgNTg6 wqDCoMKgIFBURV9QUk9UX05PTkUgKG11c3QgYmUgemVybykKPj4KPj4gUmVhZGluZyB0aGlzIHBh dGNoIGFsb25lOiB3aGF0IGhhcHBlbmVkIHRvIGJpdCAzPyBQbGVhc2UgbWVudGlvbiB0aGF0IHRo YXQgaXQKPj4gd2lsbCBiZSB1c2VkIGFzIGEgc3dhcCBwdGUgbWV0YWRhdGEgYml0ICh1ZmZkLXdw KS4KPiAKPiBXaWxsIGRvLiBJdCdzIGFsbCBhIGJpdCBhcmJpdHJhcnkgdGhvdWdoLiBJIGNvdWxk IGhhdmUgcHV0IG9mZnNldCBpbiAzLTUyLCBhbmQKPiB0aGVuIDUzIHdvdWxkIGhhdmUgYmVlbiBz cGFyZSBmb3IgdWZmZC13cC4gSSdtIG5vdCBzdXJlIHRoZXJlIGlzIGFueSBhZHZhbnRhZ2UKPiB0 byBlaXRoZXIgb3B0aW9uLgo+IAo+Pgo+Pj4gKyAqwqDCoMKgIGJpdHMgNC01MzrCoMKgwqAgc3dh cCBvZmZzZXQKPj4KPj4gU28gd2UnbGwgc3RpbGwgaGF2ZSA1MGJpdCBmb3IgdGhlIG9mZnNldCwg Z29vZC4gV2UgY291bGQgZXZlbiB1c2UgNjEtNjMgaWYgZXZlcgo+PiByZXF1aXJlZCB0byBzdG9y ZSBiaWdnZXIgUEZOcy4KPiAKPiB5ZXAsIG9yIG1vcmUgc3cgYml0cy4KPiAKPj4KPj4gTEdUTQo+ Pgo+PiBSZXZpZXdlZC1ieTogRGF2aWQgSGlsZGVuYnJhbmQgPGRhdmlkQHJlZGhhdC5jb20+Cj4g Cj4gVGhhbmtzIQo+IAo+IAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxA bGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 72F25182AE for ; Thu, 25 Apr 2024 10:37:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714041467; cv=none; b=OGdes0MqnDFCpsz86tDpMWtH84ak+eB7hioYiIO2NESlQW9OjjLe6+bPPB1MjliVWthHfu+fF+ZytM9FlVyRlcl5U/DS66pfpRk0Z6BLK84dPTcUDbFeDwec18InE1Ekze6izYHtjuGQN/sxHce8yMWmD/28N9ElPYS4mGEkyOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714041467; c=relaxed/simple; bh=Tuutq6fgzLPnVS/n+BwE2Mk0hC7utaoqSxQbOCj4/HI=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=CHpg970pO8vd7PtyoS5M7Vk+82NNUWp16DUJXN3v9+e3cadogcJHDQv1/qeydxLcoNyvppWbO07X05hv4TeKZfBTjPWeH7Wx8doodup9gTe17GwNstYvIpJwi9PT7m6S+zCl+OT6epEuiigfVf3DeJyPk0UH6j7A6/xGAWVVo5M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 18F6D1007; Thu, 25 Apr 2024 03:38:13 -0700 (PDT) Received: from [10.1.27.187] (unknown [10.1.27.187]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7467A3F64C; Thu, 25 Apr 2024 03:37:43 -0700 (PDT) Message-ID: Date: Thu, 25 Apr 2024 11:37:42 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] arm64/mm: Move PTE_PROT_NONE and PMD_PRESENT_INVALID Content-Language: en-GB From: Ryan Roberts To: David Hildenbrand , Catalin Marinas , Will Deacon , Joey Gouly , Ard Biesheuvel , Mark Rutland , Anshuman Khandual , Peter Xu , Mike Rapoport , Shivansh Vij Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20240424111017.3160195-1-ryan.roberts@arm.com> <20240424111017.3160195-2-ryan.roberts@arm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 25/04/2024 11:29, Ryan Roberts wrote: > On 25/04/2024 10:16, David Hildenbrand wrote: >> On 24.04.24 13:10, Ryan Roberts wrote: >>> Previously PTE_PROT_NONE was occupying bit 58, one of the bits reserved >>> for SW use when the PTE is valid. This is a waste of those precious SW >>> bits since PTE_PROT_NONE can only ever be set when valid is clear. >>> Instead let's overlay it on what would be a HW bit if valid was set. >>> >>> We need to be careful about which HW bit to choose since some of them >>> must be preserved; when pte_present() is true (as it is for a >>> PTE_PROT_NONE pte), it is legitimate for the core to call various >>> accessors, e.g. pte_dirty(), pte_write() etc. There are also some >>> accessors that are private to the arch which must continue to be >>> honoured, e.g. pte_user(), pte_user_exec() etc. >>> >>> So we choose to overlay PTE_UXN; This effectively means that whenever a >>> pte has PTE_PROT_NONE set, it will always report pte_user_exec() == >>> false, which is obviously always correct. >>> >>> As a result of this change, we must shuffle the layout of the >>> arch-specific swap pte so that PTE_PROT_NONE is always zero and not >>> overlapping with any other field. As a result of this, there is no way >>> to keep the `type` field contiguous without conflicting with >>> PMD_PRESENT_INVALID (bit 59), which must also be 0 for a swap pte. So >>> let's move PMD_PRESENT_INVALID to bit 60. >> >> A note that some archs split/re-combine type and/or offset, to make use of every >> bit possible :) But that's mostly relevant for 32bit. >> >> (and as long as PFNs can still fit into the swp offset for migration entries etc.) > > Yeah, I considered splitting the type or offset field to avoid moving > PMD_PRESENT_INVALID, but thought it was better to avoid the extra mask and shift. Also, IMHO we shouldn't really need to reserve PMD_PRESENT_INVALID for swap ptes; it would be cleaner to have one bit that defines "present" when valid is clear (similar to PTE_PROT_NONE today) then another bit which is only defined when "present && !valid" which tells us if this is PTE_PROT_NONE or PMD_PRESENT_INVALID (I don't think you can ever have both at the same time?). But there is a problem with this: __split_huge_pmd_locked() calls pmdp_invalidate() for a pmd before it determines that it is pmd_present(). So the PMD_PRESENT_INVALID can be set in a swap pte today. That feels wrong to me, but was trying to avoid the whole thing unravelling so didn't persue. > >> >>> >>> In the end, this frees up bit 58 for future use as a proper SW bit (e.g. >>> soft-dirty or uffd-wp). >> >> I was briefly confused about how you would use these bits as SW bits for swap >> PTEs (which you can't as they overlay the type). See below regarding bit 3. >> >> I would have said here "proper SW bit for present PTEs". > > Yes; I'll clarify in the next version. > >> >>> >>> Signed-off-by: Ryan Roberts >>> --- >>>   arch/arm64/include/asm/pgtable-prot.h |  4 ++-- >>>   arch/arm64/include/asm/pgtable.h      | 16 +++++++++------- >>>   2 files changed, 11 insertions(+), 9 deletions(-) >>> >>> diff --git a/arch/arm64/include/asm/pgtable-prot.h >>> b/arch/arm64/include/asm/pgtable-prot.h >>> index dd9ee67d1d87..ef952d69fd04 100644 >>> --- a/arch/arm64/include/asm/pgtable-prot.h >>> +++ b/arch/arm64/include/asm/pgtable-prot.h >>> @@ -18,14 +18,14 @@ >>>   #define PTE_DIRTY        (_AT(pteval_t, 1) << 55) >>>   #define PTE_SPECIAL        (_AT(pteval_t, 1) << 56) >>>   #define PTE_DEVMAP        (_AT(pteval_t, 1) << 57) >>> -#define PTE_PROT_NONE        (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */ >>> +#define PTE_PROT_NONE        (PTE_UXN)         /* Reuse PTE_UXN; only when >>> !PTE_VALID */ >>>     /* >>>    * This bit indicates that the entry is present i.e. pmd_page() >>>    * still points to a valid huge page in memory even if the pmd >>>    * has been invalidated. >>>    */ >>> -#define PMD_PRESENT_INVALID    (_AT(pteval_t, 1) << 59) /* only when >>> !PMD_SECT_VALID */ >>> +#define PMD_PRESENT_INVALID    (_AT(pteval_t, 1) << 60) /* only when >>> !PMD_SECT_VALID */ >>>     #define _PROT_DEFAULT        (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED) >>>   #define _PROT_SECT_DEFAULT    (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S) >>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >>> index afdd56d26ad7..23aabff4fa6f 100644 >>> --- a/arch/arm64/include/asm/pgtable.h >>> +++ b/arch/arm64/include/asm/pgtable.h >>> @@ -1248,20 +1248,22 @@ static inline pmd_t pmdp_establish(struct >>> vm_area_struct *vma, >>>    * Encode and decode a swap entry: >>>    *    bits 0-1:    present (must be zero) >>>    *    bits 2:        remember PG_anon_exclusive >>> - *    bits 3-7:    swap type >>> - *    bits 8-57:    swap offset >>> - *    bit  58:    PTE_PROT_NONE (must be zero) >> >> Reading this patch alone: what happened to bit 3? Please mention that that it >> will be used as a swap pte metadata bit (uffd-wp). > > Will do. It's all a bit arbitrary though. I could have put offset in 3-52, and > then 53 would have been spare for uffd-wp. I'm not sure there is any advantage > to either option. > >> >>> + *    bits 4-53:    swap offset >> >> So we'll still have 50bit for the offset, good. We could even use 61-63 if ever >> required to store bigger PFNs. > > yep, or more sw bits. > >> >> LGTM >> >> Reviewed-by: David Hildenbrand > > Thanks! > >