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 2022DEA7195 for ; Sun, 19 Apr 2026 10:41:33 +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-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID: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=Swi5niYl9xhApFDvsEd2yMgnr0uOBrYnJ6H/IS3AgIY=; b=UUY4zepQV7mQH2LI76Mpu6rK5F kUwHujpy4b8IXyUk4vb3x7aQxymQ5X9V70iHB6ebt8/47CwojAMTNUeO1TjgpT1e4QyeXXT+fZPYT ZpYrmHg2uX4MYYHiGJ/B96c6MPCfAt/D0YVIAupwKAya45mdgOxiPx20IS5VyndfV2XwYeS3z1mI6 t3BoPgqV/qP48Vuit5ttvIiYNojHZhabomf6tVN0NqLXsSa2aQzxEiup5TrXecHYfhu1PMu5fZ8jV w1YxdN8HU+oJYuucJQE/gsiAlVYpcXqskwaf7ZYtIbsdszLPISWPJMHh/yirncHVMh8GuicbQMhhO +lEOsk7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wEPah-00000005i7P-0ZDo; Sun, 19 Apr 2026 10:41:27 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wEPae-00000005i71-1RFx for linux-arm-kernel@lists.infradead.org; Sun, 19 Apr 2026 10:41:25 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 137F74333A; Sun, 19 Apr 2026 10:41:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7CF6C2BCB7; Sun, 19 Apr 2026 10:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776595280; bh=LAIQFEbnaUquFHk2b6GIMNU7b8Bu+5PRFwtbx+UqY0o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gB0CKlByXWXs8jyP6JohfSBJudqFkFOMTl5zUyKA+qzXWnnJiWQ1bQJdiIFrtxGvL 34bx74gukoDmNYcCm9NOUSGFjZo1mZUBAcNB3XGEpc4Xho2+e0ZMpDS8bYpskzNDCc 00UBjh75dX6I1N2lOYCzAqZFaD3TFSEbd+geF5UyWADAnjRjqqQjuKSlKD7dIkO2sj 1hhSWRO+FOyO38e8840rl/lHtGhixcUJYi/ehKfsSZfRDYHrD4R4dVT0uJQkT1XMgI eli3Nba4lqpuNzE40Cr8t3TdCjgcOytWiFQxE7cyKRgBQufFZdjgiOmL3epkRfyl3N TL6wsRl7bqC+w== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wEPaY-0000000Cocy-0x2N; Sun, 19 Apr 2026 10:41:18 +0000 Date: Sun, 19 Apr 2026 11:41:17 +0100 Message-ID: <87pl3vb5bm.wl-maz@kernel.org> From: Marc Zyngier To: Yeoreum Yun Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com, roberto.sassu@huawei.com, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, sudeep.holla@kernel.org, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org Subject: Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver In-Reply-To: References: <20260417175759.3191279-1-yeoreum.yun@arm.com> <20260417175759.3191279-5-yeoreum.yun@arm.com> <87se8sbozv.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: yeoreum.yun@arm.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com, roberto.sassu@huawei.com, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, sudeep.holla@kernel.org, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260419_034124_473199_7E4C012D X-CRM114-Status: GOOD ( 22.16 ) 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 Sat, 18 Apr 2026 11:34:30 +0100, Yeoreum Yun wrote: > > > > @@ -2035,6 +2037,16 @@ static int __init ffa_init(void) > > > u32 buf_sz; > > > size_t rxtx_bufsz = SZ_4K; > > > > > > + /* > > > + * When pKVM is enabled, the FF-A driver must be initialized > > > + * after pKVM initialization. Otherwise, pKVM cannot negotiate > > > + * the FF-A version or obtain RX/TX buffer information, > > > + * which leads to failures in FF-A calls. > > > + */ > > > + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() && > > > + !is_kvm_arm_initialised()) > > > + return -EPROBE_DEFER; > > > + > > > > That's still fundamentally wrong: pkvm is not ready until > > finalize_pkvm() has finished, and that's not indicated by > > is_kvm_arm_initialised(). > > Thanks. I miss the TSC bit set in here. That's the least of the problems. None of the infrastructure is in place at this stage... > IMHO, I'd like to make an new state check function -- > is_pkvm_arm_initialised() so that ff-a driver to know whether > pkvm is initialised. Doesn't sound great, TBH. > or any other suggestion? Instead of adding more esoteric predicates, I'd rather you build on an existing infrastructure. You have a dependency on KVM, use something that is designed to enforce dependencies. Device links spring to mind as something designed for that. Can you look into enabling this for KVM? If that's possible, then it should be easy enough to delay the actual KVM registration after pKVM is finalised. Thanks, M. -- Jazz isn't dead. It just smells funny.