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 B7D26C52D7D for ; Fri, 16 Aug 2024 13:22:06 +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=QAZI5M7tg66YHmWsuqL4lJI0rAcsR3dCW2WeL9NIkds=; b=n4FBth789AKZpRlMumC0xXO2hX 6bk/DnzJVo8Q2b78znaVL5V0LNz4v/QPZymJ/UZw8kNPVoVMJ8pn+jSh2Z6QzCm+82tV3Jitv4j7V G0TbIfys5cd6Wwi3AaBo/ZbElnCsrJtC970Qc1/bjr6mlecDEja5OnbrMwxzttDJl17rUf2MXF4a3 kmIDu45XxmxvwqzvsL4mR4CrM4f1vgnyIS3tn+t1sPaEIxVJVzyeS6O+sjQRYwFFxBGVl3QRspEFN Mv1q3sAh/o4REvD5InS2KFqZdXC5f/r8Xb8Lqrp7QqSZr8h8ercTiIq6h/oEgI++YRaQ5Y5CUkIo2 qzOooyWg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sewts-0000000D1D2-3NDr; Fri, 16 Aug 2024 13:21:52 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sewtC-0000000D12x-28cI for linux-arm-kernel@lists.infradead.org; Fri, 16 Aug 2024 13:21:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9B2C861DF7; Fri, 16 Aug 2024 13:21:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B88EC32782; Fri, 16 Aug 2024 13:21:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723814469; bh=a2Kf6a8V9/SSavactzIhoatEiARq9RMYi5B2/3we3eo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t1Ux+NDMqLquWHD24RThGYzsYU5Ru0ybzHSSg6uRINnbKY6yKpzOy8Iyyb2K1xmkH Xj48wX2XIWpHykMiimGieQQyQEu/6oCgfzRG1ljEhCTGTqB4griDrOsx0pe2iALSZd OR/lkakZ8L6T0qy3o57lEtnliFPctKWHYFA5O7w9yYOaXJtX24YmZJurAQGMOEEYeO PoB7SDkiuw9NJs5GJ2qc60Q7OEAHvcGKeH4zZ8hrrdCjVvCaUXE5+t7wfvDMKo9hYS CxbfPBgvcV6AK04uAdMge/h6yQaf4B+y3ywwPXpDobOoMXMO/7mqHESOl29Zx4C2Yd i9RTMYO38baog== Date: Fri, 16 Aug 2024 14:21:03 +0100 From: Will Deacon To: Nicolin Chen Cc: robin.murphy@arm.com, joro@8bytes.org, jgg@nvidia.com, thierry.reding@gmail.com, vdumpa@nvidia.com, jonathanh@nvidia.com, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH v11 9/9] iommu/tegra241-cmdqv: Limit CMDs for guest owned VINTF Message-ID: <20240816132103.GA24411@willie-the-truck> References: <153fb887cf4bf6318c6f313a4be9b40a25a24e7d.1722993435.git.nicolinc@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153fb887cf4bf6318c6f313a4be9b40a25a24e7d.1722993435.git.nicolinc@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240816_062110_687721_DBF0DFDE X-CRM114-Status: GOOD ( 22.36 ) 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 Tue, Aug 06, 2024 at 07:11:54PM -0700, Nicolin Chen wrote: > When VCMDQs are assigned to a VINTF owned by a guest (HYP_OWN bit unset), > only TLB and ATC invalidation commands are supported by the VCMDQ HW. So, > add a new helper to scan the input cmd to make sure it is supported when > selecting a queue, though this assumes that SMMUv3 driver will only add > the same type of commands into an arm_smmu_cmdq_batch as it does today. > > Note that the guest VM shouldn't have HYP_OWN bit being set regardless of > guest kernel driver writing it or not, i.e. the hypervisor running in the > host OS should wire this bit to zero when trapping a write access to this > VINTF_CONFIG register from a guest kernel. > > Reviewed-by: Jason Gunthorpe > Signed-off-by: Nicolin Chen > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 22 +++++++----- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 +- > .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 35 ++++++++++++++++++- > 3 files changed, 49 insertions(+), 11 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index 18d940c65e2c..8ff8e264d5e7 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -336,12 +336,13 @@ static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent) > return 0; > } > > -static struct arm_smmu_cmdq *arm_smmu_get_cmdq(struct arm_smmu_device *smmu) > +static struct arm_smmu_cmdq *arm_smmu_get_cmdq(struct arm_smmu_device *smmu, > + u8 opcode) > { > struct arm_smmu_cmdq *cmdq = NULL; > > if (smmu->impl && smmu->impl->get_secondary_cmdq) > - cmdq = smmu->impl->get_secondary_cmdq(smmu); > + cmdq = smmu->impl->get_secondary_cmdq(smmu, opcode); > > return cmdq ?: &smmu->cmdq; > } > @@ -889,7 +890,7 @@ static int __arm_smmu_cmdq_issue_cmd(struct arm_smmu_device *smmu, > } > > return arm_smmu_cmdq_issue_cmdlist( > - smmu, arm_smmu_get_cmdq(smmu), cmd, 1, sync); > + smmu, arm_smmu_get_cmdq(smmu, ent->opcode), cmd, 1, sync); > } > > static int arm_smmu_cmdq_issue_cmd(struct arm_smmu_device *smmu, > @@ -905,10 +906,13 @@ static int arm_smmu_cmdq_issue_cmd_with_sync(struct arm_smmu_device *smmu, > } > > static void arm_smmu_cmdq_batch_init(struct arm_smmu_device *smmu, > - struct arm_smmu_cmdq_batch *cmds) > + struct arm_smmu_cmdq_batch *cmds, > + u8 opcode) > { > + WARN_ON_ONCE(!opcode); This seems like a fairly arbitrary warning. Remove it? > + > cmds->num = 0; > - cmds->cmdq = arm_smmu_get_cmdq(smmu); > + cmds->cmdq = arm_smmu_get_cmdq(smmu, opcode); If we stashed the opcode here, we could actually just enforce that all commands in the batch are the same type in arm_smmu_cmdq_batch_add(). Would that work better for you or not? Will