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 00F931090247 for ; Thu, 19 Mar 2026 16:02:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To: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=Uv6xjD+xq1ByY66Ck7xiD8Jqhn5Jv0DO6kZ44bzcIfI=; b=GCnUgIdOMfKs1uFOVdjBZnHE6D wNCfilDI82wxvbjyDple7lw5MBmjbyy2Xdi+/eZIiBqpC6Ns7gWUDs/z8ALd3/dyzdLJYhohnTEQG Xj2HRRFTJ/qqaEhbnQTDBrPcXGwjO96/28/Sy1UP6VUMBn9fYKa2h30S1DifPG6IzLyjDQ6OI8HQA oOSTT38lKfWsTRDut3mOAxuMH8ACjDVI/IzST9TRIPATqzLJDRuzkxdrWwiq88uBOacHE9nCxP9Jg ilzbPvjRqCXT4AQkOdmB0s5sjpkS8Cp9Np32gLfDJUnVxV0GBvm8r03xd8/3EY/oT/pTIKCNJuR2Y eylOB0BA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w3FpR-0000000B1hl-1XPb; Thu, 19 Mar 2026 16:02:33 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w3FpM-0000000B1gd-3CHB for linux-arm-kernel@lists.infradead.org; Thu, 19 Mar 2026 16:02:31 +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 AA1BB1477; Thu, 19 Mar 2026 09:02:19 -0700 (PDT) Received: from [10.1.35.24] (e122027.cambridge.arm.com [10.1.35.24]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1AA213F778; Thu, 19 Mar 2026 09:02:20 -0700 (PDT) Message-ID: Date: Thu, 19 Mar 2026 16:02:18 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v13 36/48] arm64: RMI: Always use 4k pages for realms To: Joey Gouly Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve References: <20260318155413.793430-1-steven.price@arm.com> <20260318155413.793430-37-steven.price@arm.com> <20260319102454.GB3942350@e124191.cambridge.arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: <20260319102454.GB3942350@e124191.cambridge.arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260319_090228_923487_0357FA70 X-CRM114-Status: GOOD ( 22.12 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 19/03/2026 10:24, Joey Gouly wrote: > Hi, > > On Wed, Mar 18, 2026 at 03:54:00PM +0000, Steven Price wrote: >> Guest_memfd doesn't yet natively support huge pages, and there are >> currently difficulties for a VMM to manage huge pages efficiently so for >> now always split up mappings to PTE (4k). >> >> The two issues that need progressing before supporting huge pages for >> realms are: >> >> 1. guest_memfd needs to be able to allocate from an appropriate >> allocator which can provide huge pages. >> >> 2. The VMM needs to be able to repurpose private memory for a shared >> mapping when the guest VM requests memory is transitioned. Because >> this can happen at a 4k granularity it isn't possible to >> free/reallocate while huge pages are in use. Allowing the VMM to >> mmap() the shared portion of a huge page would allow the huge page >> to be recreated when the memory is unshared and made protected again. >> >> These two issues are not specific to realms and don't affect the realm >> API, so for now just break everything down to 4k pages in the RMM >> controlled stage 2. Future work can add huge page support without >> changing the uAPI. > > The commit title/message mention 4K, but should probably say PAGE_SIZE or > something now that RMM isn't fixed to 4K. Indeed - this is all PAGE_SIZE not 4k any more. Also hopefully the reasons for this patch are also going to disappear soon. (2) above isn't really very true any more (we do support mmap() from guest_memfd). Thanks, Steve > Thanks, > Joey > >> >> Signed-off-by: Steven Price >> Reviewed-by: Gavin Shan >> Reviewed-by: Suzuki K Poulose >> --- >> Changes since v7: >> * Rewritten commit message >> --- >> arch/arm64/kvm/mmu.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c >> index 73c18c2861a2..ad1300f366df 100644 >> --- a/arch/arm64/kvm/mmu.c >> +++ b/arch/arm64/kvm/mmu.c >> @@ -1761,11 +1761,14 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, >> write_fault = kvm_is_write_fault(vcpu); >> >> /* >> - * Realms cannot map protected pages read-only >> + * Realms cannot map protected pages read-only, also force PTE mappings >> + * for Realms. >> * FIXME: It should be possible to map unprotected pages read-only >> */ >> - if (vcpu_is_rec(vcpu)) >> + if (vcpu_is_rec(vcpu)) { >> write_fault = true; >> + force_pte = true; >> + } >> >> exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu); >> VM_WARN_ON_ONCE(write_fault && exec_fault); >> -- >> 2.43.0 >> >>