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 9F05ECA1007 for ; Fri, 30 Aug 2024 15:56: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=vMV9s9NPjGDQY2Yp6Z/+u0koZWrk3GfLayXxjW435LQ=; b=3kUAyfaisWmr8jtwKEVCIPzppR zTJwgeOYYw4RLZeiGnPPjV8nAlUoMzMRgaShJ5yrGMGwcJMseFU9eT5XYkBPYeMt/w4XbeYBzNJut wUl32zCQKbg1PxpKoKzaoNakWLu9iITn6vLpOgB4L3wk5OBJ7aMMkc1mJzgA9B+s+bmi5x3nIowxS zJwlcfbcR3ZBEG7dJwNvdT8HE6O7FER0J/ppTnOuETE39iry/ztpT/KpvlYu3B3G3oCuUbAeaEMjU oFGZPqq5Axcf366CgPl3vw90Av0qBgZ1VZzon/EB4uSh/y4tvm4zvNWu6RK0YuwMT26MZ3G4IvQ6w FfmErLqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sk3z6-00000006uKn-1I4o; Fri, 30 Aug 2024 15:56:24 +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 1sk3xZ-00000006to3-2GiR for linux-arm-kernel@lists.infradead.org; Fri, 30 Aug 2024 15:54:51 +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 C59C11063; Fri, 30 Aug 2024 08:55:14 -0700 (PDT) Received: from [10.1.30.22] (e122027.cambridge.arm.com [10.1.30.22]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 543CC3F762; Fri, 30 Aug 2024 08:54:45 -0700 (PDT) Message-ID: <2e8caa91-bf66-4555-87b3-52f469b2c7ef@arm.com> Date: Fri, 30 Aug 2024 16:54:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 05/19] arm64: Detect if in a realm and set RIPAS RAM To: Catalin Marinas Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, 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 , Gavin Shan , Shanker Donthineni , Alper Gun References: <20240819131924.372366-1-steven.price@arm.com> <20240819131924.372366-6-steven.price@arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: 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-20240830_085449_697844_FF451C5A X-CRM114-Status: GOOD ( 22.18 ) 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 26/08/2024 11:03, Catalin Marinas wrote: > On Mon, Aug 19, 2024 at 02:19:10PM +0100, Steven Price wrote: >> +static bool rsi_version_matches(void) >> +{ >> + unsigned long ver_lower, ver_higher; >> + unsigned long ret = rsi_request_version(RSI_ABI_VERSION, >> + &ver_lower, >> + &ver_higher); >> + >> + if (ret == SMCCC_RET_NOT_SUPPORTED) >> + return false; >> + >> + if (ret != RSI_SUCCESS) { >> + pr_err("RME: RMM doesn't support RSI version %lu.%lu. Supported range: %lu.%lu-%lu.%lu\n", >> + RSI_ABI_VERSION_MAJOR, RSI_ABI_VERSION_MINOR, >> + RSI_ABI_VERSION_GET_MAJOR(ver_lower), >> + RSI_ABI_VERSION_GET_MINOR(ver_lower), >> + RSI_ABI_VERSION_GET_MAJOR(ver_higher), >> + RSI_ABI_VERSION_GET_MINOR(ver_higher)); >> + return false; >> + } >> + >> + pr_info("RME: Using RSI version %lu.%lu\n", >> + RSI_ABI_VERSION_GET_MAJOR(ver_lower), >> + RSI_ABI_VERSION_GET_MINOR(ver_lower)); >> + >> + return true; >> +} > > I don't have the spec at hand now (on a plane) but given the possibility > of a 1.0 guest regressing on later RMM versions, I wonder whether we > should simply bail out if it's not an exact version match. I forgot what > the spec says about returned ranges (they were pretty confusing last > time I checked). Well the idea at least is that the RMM can tell us that it is providing a 1.0 compatible interface. So it might be supporting 1.x but it's promising that what it's providing is 1.0 compatible. Indeed the spec allows the RMM to emulate 1.0 while supporting a higher (incompatible) interface as well - which is where the version ranges come in. So in the future we might negotiate versions with the RMM, or opportunistically use newer features if the RMM provides them. But obviously for now the guest is only 1.0. I'd prefer not to add an exact version match because then upgrading the RMM would break existing guests and would probably lead to pressure for the RMM to simply lie to guests to avoid them breaking on upgrade. >> + >> +void __init arm64_rsi_setup_memory(void) >> +{ >> + u64 i; >> + phys_addr_t start, end; >> + >> + if (!is_realm_world()) >> + return; >> + >> + /* >> + * Iterate over the available memory ranges and convert the state to >> + * protected memory. We should take extra care to ensure that we DO NOT >> + * permit any "DESTROYED" pages to be converted to "RAM". >> + * >> + * BUG_ON is used because if the attempt to switch the memory to >> + * protected has failed here, then future accesses to the memory are >> + * simply going to be reflected as a SEA (Synchronous External Abort) >> + * which we can't handle. Bailing out early prevents the guest limping >> + * on and dying later. >> + */ >> + for_each_mem_range(i, &start, &end) { >> + BUG_ON(rsi_set_memory_range_protected_safe(start, end)); >> + } > > Would it help debugging if we print the memory ranges as well rather > than just a BUG_ON()? > Yes that would probably be useful - I'll fix that. Thanks, Steve