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 BBED7C2BA18 for ; Mon, 17 Jun 2024 11:23:29 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sM9D3IqfgB50OxP9LSaIkbOJs5yF44MMVnRSPz65e9Q=; b=gK9XVj+kUW0ps909B3PSr6Xve6 HG0xA6owPWAt4ryQEShgkGnCW6peh+qIZ48NffgcDgzz6B+SwJrDkiIqDrVrWIdLW6xZ5m14PsHvl 59CJhS018QbYXWUaVHDhtL7n+u5Ldb2CsSyRORs575CPGSgiKIfLYK682W6cmLslyP/fI+fJ5x3c7 18Dt9AAVrRLMogCgxExYsD65jaAa4Rg7D40X1NUHBiRqaNfp+rGzsIgt9cq+PKi6ru0CBPVEBHa83 0fWkpgMtvO9jiYtfCzVTyFyV9/4Hmi/Kp3VBHmOkNd9761rRUYcTyzFGJsc5VrEu9yZy6oLwjhTFb bEacO/Cw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJASD-0000000AT57-3XZl; Mon, 17 Jun 2024 11:23:17 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJASA-0000000AT1g-0lJq for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 11:23:16 +0000 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-35f0aeff7a8so3497256f8f.2 for ; Mon, 17 Jun 2024 04:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1718623391; x=1719228191; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=sM9D3IqfgB50OxP9LSaIkbOJs5yF44MMVnRSPz65e9Q=; b=jm3+VKHklieZzye8mb8yw2t5aHAJxr4Gz4DA4zYuNI76Aqzwa8+cnxx0Gg1hXYN686 tk8uoLs35eWkE0Q6AosXPOs8YLeUVGNjLUf5pSswf0HJBr6CzDkF+AA2Zxy2CFovM6Q3 r0mk62DkZw1XcmLA0K5CPp7BUWKTj8rTh+UmFJgDNom4pdp+GxIt2Ti7FP3Q0XqhfTSY DjjTUFLxzVFEzfiu0w+WGFnM8edtoxcDaZvzpc4Jgw0lgwG5Eq6iUU7TuFYGNfAE3e5o E9PhiCl4srtlmgo5LdAx/8kW7C6Ux3vd2apvLW7uyRygZCTmvMBvDlW5147MZ4+1P55z LIhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718623391; x=1719228191; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sM9D3IqfgB50OxP9LSaIkbOJs5yF44MMVnRSPz65e9Q=; b=M6OB/Aa00YFaT9nEZXDqNDN8CZW65+hchK6GQnXC1K5awSviHuteqbk1DOmR4/SbQc b/Pi/nKkevlsjGzL7vQB8BJ8LZkWkx7X1nSbm5CCa2EpCs+OyXISG1zhAZkrHuZkLWnd 1B2KTCyVNCyrrlacfS2HElItbKt6EnFtBPwWrKeGxLhpmkFfo3Q4Vi+SQHO7UtvYHAna BGin+sviHK1PsFYA8LP8hOyBqi8t7vbHY3yM4sWHX0ltHSosjRIKJoL6gHm5FaLNUgh5 R2M4ljvOdgtD07/vltcgoD2M4tN6UCOwji83LhUEAMQEQgu8Nz2SiodTyJROuwdPVtph Y8vA== X-Forwarded-Encrypted: i=1; AJvYcCVL1KuB8BAs55k1ncPx9cGCDp+rVJWMc8TT9DYU6bGZpTVr1UO5XCgmzQo3uDK4nHTDGCCQNBy40VLQW9Mom9bQnrKphcKCk5w5LRszcw1UfLTVcnY= X-Gm-Message-State: AOJu0Yx9a21CQ0O/PNJl1yF4SKReFsTM+GDCoYXOPQ2VMHfHmOyj0afq ozH+eJUMJsSgiZwuIYjmYP8qU7PbXpnt5IDOCUYT2C3s+cRgarZfu5Lmt4OVTHc= X-Google-Smtp-Source: AGHT+IETE+Maao3JAp1ZfgvsbcmTneajMGOq/KKGP7BvZAyqnGu9qO6mLUlHKQfEume52Ehz/Rt4gQ== X-Received: by 2002:adf:f902:0:b0:360:727b:8b47 with SMTP id ffacd0b85a97d-3607a7e7c15mr8074845f8f.63.1718623390738; Mon, 17 Jun 2024 04:23:10 -0700 (PDT) Received: from myrica ([2.221.137.100]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-360750acf32sm11673653f8f.49.2024.06.17.04.23.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jun 2024 04:23:10 -0700 (PDT) Date: Mon, 17 Jun 2024 12:23:26 +0100 From: Jean-Philippe Brucker To: Peter Maydell Cc: Suzuki K Poulose , Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , 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 , fvogt@suse.de Subject: Re: [PATCH v3 02/14] arm64: Detect if in a realm and set RIPAS RAM Message-ID: <20240617112326.GA1193@myrica> References: <20240605093006.145492-1-steven.price@arm.com> <20240605093006.145492-3-steven.price@arm.com> <20240612104023.GB4602@myrica> <3301ddd8-f088-48e3-bfac-460891698eac@arm.com> <20240613105107.GC417776@myrica> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240617_042314_342302_6D197730 X-CRM114-Status: GOOD ( 38.21 ) 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 Mon, Jun 17, 2024 at 11:27:31AM +0100, Peter Maydell wrote: > On Thu, 13 Jun 2024 at 11:50, Jean-Philippe Brucker > wrote: > > > > On Wed, Jun 12, 2024 at 11:59:22AM +0100, Suzuki K Poulose wrote: > > > On 12/06/2024 11:40, Jean-Philippe Brucker wrote: > > > > On Wed, Jun 05, 2024 at 10:29:54AM +0100, Steven Price wrote: > > > > > From: Suzuki K Poulose > > > > > > > > > > Detect that the VM is a realm guest by the presence of the RSI > > > > > interface. > > > > > > > > > > If in a realm then all memory needs to be marked as RIPAS RAM initially, > > > > > the loader may or may not have done this for us. To be sure iterate over > > > > > all RAM and mark it as such. Any failure is fatal as that implies the > > > > > RAM regions passed to Linux are incorrect - which would mean failing > > > > > later when attempting to access non-existent RAM. > > > > > > > > > > Signed-off-by: Suzuki K Poulose > > > > > Co-developed-by: Steven Price > > > > > Signed-off-by: Steven Price > > > > > > > > > +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); > > > > > > > > There is a regression on QEMU TCG (in emulation mode, not running under KVM): > > > > > > > > qemu-system-aarch64 -M virt -cpu max -kernel Image -nographic > > > > > > > > This doesn't implement EL3 or EL2, so SMC is UNDEFINED (DDI0487J.a R_HMXQS), > > > > and we end up with an undef instruction exception. So this patch would > > > > also break hardware that only implements EL1 (I don't know if it exists). > > > > > > Thanks for the report, Could we not check ID_AA64PFR0_EL1.EL3 >= 0 ? I > > > think we do this for kvm-unit-tests, we need the same here. > > > > Good point, it also fixes this case and is simpler. It assumes RMM doesn't > > hide this field, but I can't think of a reason it would. > > > > This command won't work anymore: > > > > qemu-system-aarch64 -M virt,secure=on -cpu max -kernel Image -nographic > > > > implements EL3 and SMC still treated as undef. QEMU has a special case for > > starting at EL2 in this case, but I couldn't find what this is for. > > That's a bit of an odd config, because it says "emulate EL3 but > never use it". QEMU's boot loader starts the kernel at EL2 because > the kernel boot protocol requires that (this is more relevant on > boards other than virt where EL3 is not command-line disableable). > I have a feeling we've occasionally found that somebody's had some > corner case reason to use it, though. (eg > https://gitlab.com/qemu-project/qemu/-/issues/1899 > is from somebody who says they use this when booting Windows 11 because > it asserts at boot time that EL3 is present and won't boot otherwise.) Thanks for the pointer. In this case it looks like Linux was used as reproducer and not the main use-case, though I wonder if some CIs regularly boot this particular configuration. > > Your underlying problem here seems to be that you don't have > a way for the firmware to say "hey, SMC works, you can use it" ? We do: SMCCC recommends to look at the PSCI conduit declared in DT/ACPI. Given that RMM mandates using the SMC conduit for both PSCI and RSI calls, we could use this discovery mechanism here. The problem is that we have to discover it very early at boot, before the DT infrastructure is ready, so the implementation is a little awkward. I did post one earlier in this thread but it doesn't yet account for ACPI-only boot, which will need something similar. Testing ID_AA64PFR0_EL1.EL3 would be much simpler, but it would break this config. Thanks, Jean