From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F0EF62E2667 for ; Sun, 30 Nov 2025 23:06:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764543988; cv=none; b=lSFLRObAaA+EWKg7uNYsSBCGbka0wOD64TksnGvL1CN+1I31k6dJKH8U18Wy4O39a5pEbl265CkMV/AOucK7EUqriep4RUKCPbcX/xsmzbJdQ0mNHUQ07deTlQxXc9HyzWQXYstSRIcNmO6faFbYhpQUEZVdJl7AztUAewYA8B4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764543988; c=relaxed/simple; bh=g5yvOzo7c6xX6rYopnZszTcS5wvfEhudD5Qk2af7SaA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RXDFcHPYpirNx1LIy0nzd0tvsmkk5RSmCjctEggzBxCS6fLtCh9FVZ9Kc1XTtv1RRFafsOUldA/+3kbJBtiNbcItwciyDu0RYJfvSPwhe08Ud7Bxb+eIumCRI/U6jEZcEjRWRYjVNpQIh9V4V3nzAP35x07w+QhnvXbIWyBu/jc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=XBU5NBBF; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="XBU5NBBF" Received: from localhost (unknown [52.148.138.235]) by linux.microsoft.com (Postfix) with ESMTPSA id EE149200DFD7; Sun, 30 Nov 2025 15:06:25 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com EE149200DFD7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1764543986; bh=RnUpxN1N4KtYTM7ucfVIdft/DvXqIYr8m/DVjMFJWjw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XBU5NBBFy6mc6MZK1lrNzAGwIV8cz5wl+jqCgLKaLjFjg1k+WLcFKDnpi38Nx7p+k Xm8f3bqETJGYM2/FD6XxHALXkWASQ1u9OufyFp0nCtfyM6q5tZjWPtVOYZhu5vsgmz MFSkJ4j8oZmpw0j148nYRagEZzNI6MGkn0RmYhYs= Date: Sun, 30 Nov 2025 15:06:24 -0800 From: Jacob Pan To: Will Deacon Cc: linux-kernel@vger.kernel.org, "iommu@lists.linux.dev" , Joerg Roedel , Mostafa Saleh , Jason Gunthorpe , Robin Murphy , Nicolin Chen , Zhang Yu , Jean Philippe-Brucker , Alexander Grest Subject: Re: [PATCH v4 1/2] iommu/arm-smmu-v3: Fix CMDQ timeout warning Message-ID: <20251130150624.000053e7@linux.microsoft.com> In-Reply-To: References: <20251114171718.42215-1-jacob.pan@linux.microsoft.com> <20251114171718.42215-2-jacob.pan@linux.microsoft.com> Organization: LSG X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; x86_64-w64-mingw32) 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-Transfer-Encoding: 7bit Hi Will, On Tue, 25 Nov 2025 17:19:16 +0000 Will Deacon wrote: > On Fri, Nov 14, 2025 at 09:17:17AM -0800, Jacob Pan wrote: > > While polling for n spaces in the cmdq, the current code instead > > checks if the queue is full. If the queue is almost full but not > > enough space ( > even if the polling has exceeded timeout limit. > > > > The existing arm_smmu_cmdq_poll_until_not_full() doesn't fit > > efficiently nor ideally to the only caller > > arm_smmu_cmdq_issue_cmdlist(): > > - It uses a new timer at every single call, which fails to limit > > to the preset ARM_SMMU_POLL_TIMEOUT_US per issue. > > - It has a redundant internal queue_full(), which doesn't detect > > whether there is a enough space for number of n commands. > > > > This patch polls for the availability of exact space instead of > > full and emit timeout warning accordingly. > > > > Fixes: 587e6c10a7ce ("iommu/arm-smmu-v3: Reduce contention during > > command-queue insertion") Co-developed-by: Yu Zhang > > Signed-off-by: Yu Zhang > > Signed-off-by: Jacob Pan > > > > I'm assuming you're seeing problems with an emulated command queue? > Any chance you could make that bigger? > This is not related to queue size, but rather a logic issue when anytime queue is nearly full. > > @@ -804,12 +794,13 @@ int arm_smmu_cmdq_issue_cmdlist(struct > > arm_smmu_device *smmu, local_irq_save(flags); > > llq.val = READ_ONCE(cmdq->q.llq.val); > > do { > > + struct arm_smmu_queue_poll qp; > > u64 old; > > > > + queue_poll_init(smmu, &qp); > > while (!queue_has_space(&llq, n + sync)) { > > local_irq_restore(flags); > > - if > > (arm_smmu_cmdq_poll_until_not_full(smmu, cmdq, &llq)) > > - dev_err_ratelimited(smmu->dev, > > "CMDQ timeout\n"); > > + arm_smmu_cmdq_poll(smmu, cmdq, &llq, &qp); > > > > Isn't this broken for wfe-based polling? The SMMU only generates the > wake-up event when the queue becomes non-full. I don't see this is a problem since any interrupts such as scheduler tick can be a break evnt for WFE, no? I have also tested this with WFE on BM with no issues. HyperV VM does not support WFE.