From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53C8029B78F for ; Wed, 1 Apr 2026 17:22:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775064127; cv=none; b=Z8Kptr5MoYoeCa36ZmE65yJ8HYzXDzGe196SdGEUxo6OoP3UUlBbkEe2i+eDXFh32oNneRAEsCpFFYzMmbIHHS2QAEuxYkP3hSCHuEcsAdKiVcxugGRw6jnUUa0Xqf15TTcouVeYdN3kg3tZYv4z7tYCthU1Rpj6N1f2geTAFX0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775064127; c=relaxed/simple; bh=nfIssJp3sCyDprMsLOWWWTbEWvePk4WAb6EMj+ncKmk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XgUtlSl/6i52URXF3FGPXMq5V8P6b5v2h7JjLxGNUUufw65lAintwDZ5hXlMVI5Ji426iT+Nn6LrNsqbnqJtt4w6sP2Oznoo4tkuXN5I13+oKjekaovLPz4gggj7xVZKpEv1NlR9wJRDAW3ChCD7B0SJq96mM2pIfmEt80EbeOg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=EkpyzchR; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="EkpyzchR" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4888939d2c3so4085e9.1 for ; Wed, 01 Apr 2026 10:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775064125; x=1775668925; darn=vger.kernel.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=8FK7OAZJnMRvfLsIQNwvSj1elKc0MV4FPgcgTqTFOq0=; b=EkpyzchRlgJHNjYGWwpl8G4IDRc/h+n8ug9fxIR2yloNJbgco0/dO4/EVp20s4HnFQ AQrvpnHZi1pXodccE+Mv32EwnzT9D3/W0EDb2ZN4AKLv8sR96mBvOb19YCE9PaNJsmHx 0axfeK0SbTACdJMLnf+pjuZOvHA+8neqXjBsAgQ/IARTYd/HuliMuJji57dRQ6EL6J+S 8y3upHgvUhBPJQ7EvRi/wP5M/9Wmk7XcIjPclgdMNyhxKIr1MlB5XjpWy/lJSOgU+pl/ bkm1SqX5OZzJSiakJY2mCqtOrzfH3ROfLK10sXOr/on31HM4rg9DY8FLh3T/44foKtyH 0giw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775064125; x=1775668925; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8FK7OAZJnMRvfLsIQNwvSj1elKc0MV4FPgcgTqTFOq0=; b=f86yW3Ozk4ahyqxEfI3C/z2X/HwqHjEj53fOgn7a2Z26rm2lxT126fW957XXZ56BOr qQPpq7euLHdxp4fAgfnRgcOMeT4bDErSLY5Hsu9SNMo41FaKcPzyUMd9TNvXPjB0BJ4G FJrR0cZGt+9eeihRHx15rpxakyShkv/0Bz6KwXcwzg1TnaGr3c7ArOHay6C/w+LFpXTu 0pE9lAfRwHPBhxxtOESKR0Z2V8SpnymTp3srk9dKrha9nvHK62BFONyTpYE1ED+vVCoU 7H7XOxN6OhOPpjzlrf8a677aC/BzLyyi/8ATAEktR+vHeQaZd2Wy7H+tMRJru0DZQwlX Ct1Q== X-Forwarded-Encrypted: i=1; AJvYcCUGunZvhaJrh3ES8gZGAQ0H0iOTW1upF+8mMVtqjTGZNCCL02JfdZwOPHzJUwNyxM8yOA86kuIf/lwrXYE=@vger.kernel.org X-Gm-Message-State: AOJu0YxIZSRkS/dXeLrqfDgHlOMvsLDgEwRAzEXbXXVNLpvmZZdMHJjB Q+VPyeTjFI31ahmeQvwWy/BQ0b+M9ewkalfqHktbbSAGTSZWjDt+u6e2wsSIh1CYuw== X-Gm-Gg: ATEYQzytrcwAw2OKLvwHPbxHl2Cy67BUfhXKhMcr5bAFAmvL5jDhMWUBzgJWczequJ3 8oAKeHOJF1GgMTCuQM7xkSSgg361ouk4aJUaGsiBEmOz7SATNnb3Bwc5JddvpOFZPJYah9a8zjs Fs7u62M6Ksi+/6WEn/xDxdOIiBJ1YVit+EXvWBZHxeQZhVGVGp7UQ38s+S8JMd0GzWqMPgREVgh 8pJJw80ujgcoYoEpGPwRgNXOvmUwiYb0U31TmOGQBcThebGkQdz2Bq7eIDih6VDRsZpkzXtE3Zu UgbmzolU4jWJXD29kN1WxXx8ihNt7ePSJpBI9N/kRCld3Kd7bAsZiI88LZVRbwz5LV9zA2gIbXo O9MUZyCzQcykXYrSa5lZneHwLkOZ4HK4h3BcBGXryQ6DItGlZdwUQsZ63RkzHcbheZYokbGPdw8 sjQxoIJRnFJiBE9juSyqxFf/Licv/RhHfBXRdunwdfBLWm3vkzdRFSSnFHK/JrrvmdVfk= X-Received: by 2002:a05:600c:d8:b0:486:fd5a:18db with SMTP id 5b1f17b1804b1-4888b7a1471mr37475e9.11.1775064124308; Wed, 01 Apr 2026 10:22:04 -0700 (PDT) Received: from google.com (209.13.205.35.bc.googleusercontent.com. [35.205.13.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887c8ee2d3sm49918275e9.32.2026.04.01.10.22.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2026 10:22:03 -0700 (PDT) Date: Wed, 1 Apr 2026 17:21:58 +0000 From: Sebastian Ene To: Marc Zyngier Cc: catalin.marinas@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, joey.gouly@arm.com, korneld@google.com, mrigendra.chaubey@gmail.com, oupton@kernel.org, perlarsen@google.com, suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.com Subject: Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers Message-ID: References: <20260401123201.389906-1-sebastianene@google.com> <86341e4to0.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86341e4to0.wl-maz@kernel.org> On Wed, Apr 01, 2026 at 03:55:11PM +0100, Marc Zyngier wrote: > On Wed, 01 Apr 2026 13:32:01 +0100, > Sebastian Ene wrote: > > > > Make the SMC handlers accept a 64bit value for the function-id to keep > > it uniform with the rest of the code and prevent a u64 -> u32 -> u64 > > conversion as it currently happens when we handle PSCI. > > That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6 > G): I'm not plannig to be *overly creative*. Thanks for pointing out the ARM spec. > > "The Function Identifier is passed on W0 on every SMC and HVC > call. Its 32-bit integer value indicates which function is being > requested by the caller. It is always passed as the first argument to > every SMC or HVC call in R0 or W0." > > which indicates that it is *always* a 32bit value. > > So if you have a 64bit value somewhere, *that* should be fixed, not > propagated arbitrarily. If you have a non SMCCC call that happen to have the first 32-bits of the function-id matching either PSCI or FF-A you will end up handling them instead of forwarding it to Trustzone because func_id is declared as: DECLARE_REG(u64, func_id, host_ctxt, 0); > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible. Thanks, Sebastian