Received: by 2002:ab2:784b:0:b0:1fd:adc2:8405 with SMTP id m11csp376983lqp; Mon, 10 Jun 2024 06:58:19 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUrACzZWwX1MJmdFsgVqEYRKVIIJ+wIA6f2OrWiPp+X72gslv8QphT3nXSUZnf5H5kxd9XIUn3yld1rTNynnrIM0y1MXWYqHgFHmkrTew== X-Google-Smtp-Source: AGHT+IGPk1+6pqPw5Uj9tLuchSl4hr8cxwp7lGqz70kflCFOKu76gGj8pSHw5E2EwZVrRjDuclZ1 X-Received: by 2002:a05:6102:824:b0:48c:224:d36b with SMTP id ada2fe7eead31-48c277e4a2bmr9069920137.31.1718027899562; Mon, 10 Jun 2024 06:58:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718027899; cv=pass; d=google.com; s=arc-20160816; b=mYY+KYysnUZQTXuNljMWG6/RzSmDTyX5p2301GSD4LSHOSrU+dBnyXz9mvZMy1By7W knQ9xFzssBtgOZpnXhbxb7NKMVE2SSaVCyF2da/nN2THH1XQTJJv+iValEFf863jFbe1 TY90r8Ty7/0wm2L/AeA24pabByZm/P3+wA+joSdeJbtPD6CoX7l9iX2wdGr5FSP8khRa ZbPTJx+wR6dqPH2v2T7LgcCk3Hu7Et3+ss2bksDyyTJNTFnnlp2NM/0gqcTWjYnWSz9E aEQ5wQJQyyPfuOtV5y64OKuVHKYZDf1+McyYGmM+MJTQebXFfu8aYINoLnHRc1rKVjeO GreQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=cqlucR+zEbQOg3gO4CPXri9+gpCioGZYrsCMzP9O+xo=; fh=NDCPdPn2hiqHaiIRDYQAzsW9PK20CTia4nECGof6enU=; b=TNSTt2HAaYII4WQJYTQQrDWyL1L9NlB28nXEmkKFGcB/F48xPDfK1TM83NQNFb96ml lC11A9Hhul/E7dGuahDj0sRh60CixXszgS0tl2umLO3R/6/y67WmvNepyWYco//05eqp 9O/kL5IzdEUyHrk9FJxkWkcwkyOT8jSX2qDi9NbeNOvlPYsTZyBMki34R8nPGrPS9kWU 9JhfDy/8639vVx8FVvtDNuS5dwCQyQ3E8OgQMdszUjRcH+aBJB21w0EOEJLKhjTw392a vpcgSh5geZBv1CujOFDgMdzWa4SgY8jYBQgnkYHTIOI64s8vLMEh/F9mqZICoVd8rJ3M hNRQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-208277-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-208277-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id af79cd13be357-795604a14a3si368148785a.191.2024.06.10.06.58.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jun 2024 06:58:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-208277-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-208277-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-208277-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 90F241C22738 for ; Mon, 10 Jun 2024 13:51:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2D867155CAD; Mon, 10 Jun 2024 13:44:00 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 54EDF155CAF; Mon, 10 Jun 2024 13:43:58 +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=1718027039; cv=none; b=A7ItH5Pa6jBt6QYa7oa6bUtYu5gPaj8BFPl52alPRlzjc+Kcj0ec4WF1Y/cq6EON/rl61WRBG0ai55Ct5OnB2iDLL+U1wB6KQkhnARgFrjRaRRqQWliNsHh6vU0wCPqRpO0suWQlgVS2ZGtG7OKP+RmnuepFKABfZNd7WgK1dI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718027039; c=relaxed/simple; bh=Ey3T7Czzk6cwwe70fX0ea9XGP/cJBiYNNOvLjczPGbo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=q1fCHZyQvuZ0J2egeQ8SrED+MMHxQ6eOYJbD5jRt1g0MioNzyrO6s411VBeEmNlPoGMZSGdzOTF1H9/jbWBE5dXG0HtkEka5tgSaxApfx3w31+RXz/Ferv39NYE++oVLCW2Kv2Ge52Vk/88ve1GqAzl7vAvDzNyHejoXcojEb00= 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 83B61106F; Mon, 10 Jun 2024 06:44:22 -0700 (PDT) Received: from e122027.cambridge.arm.com (e122027.cambridge.arm.com [10.1.35.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D23043F73F; Mon, 10 Jun 2024 06:43:55 -0700 (PDT) From: Steven Price To: kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Steven Price , 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, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni Subject: [PATCH v3 30/43] arm64: RME: Always use 4k pages for realms Date: Mon, 10 Jun 2024 14:41:49 +0100 Message-Id: <20240610134202.54893-31-steven.price@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240610134202.54893-1-steven.price@arm.com> References: <20240610134202.54893-1-steven.price@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Always split up huge pages to avoid problems managing huge pages. There are two issues currently: 1. The uABI for the VMM allows populating memory on 4k boundaries even if the underlying allocator (e.g. hugetlbfs) is using a larger page size. Using a memfd for private allocations will push this issue onto the VMM as it will need to respect the granularity of the allocator. 2. The guest is able to request arbitrary ranges to be remapped as shared. Again with a memfd approach it will be up to the VMM to deal with the complexity and either overmap (need the huge mapping and add an additional 'overlapping' shared mapping) or reject the request as invalid due to the use of a huge page allocator. For now just break everything down to 4k pages in the RMM controlled stage 2. Signed-off-by: Steven Price --- arch/arm64/kvm/mmu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 5eb5af0ff5d7..cdbd5a29539a 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1534,6 +1534,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, if (logging_active) { force_pte = true; vma_shift = PAGE_SHIFT; + } else if (kvm_is_realm(kvm)) { + // Force PTE level mappings for realms + force_pte = true; + vma_shift = PAGE_SHIFT; } else { vma_shift = get_vma_page_shift(vma, hva); } -- 2.34.1