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 B9970C531DC for ; Tue, 20 Aug 2024 19:54:03 +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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yp4vfYpCGOdYBS/m6HmbaB98zMN6C60AGpKXCWzp5n0=; b=AfCjLhZVWsrVqGMyrcynPynSoo l68GowrDpCUFRtrZDLKMoWtVA6oW1+AoMwtD3kTkzZmR9eIdll2Hr22JimZPuX/wSYUCOuJu1I9II 9sp7+UiccYHQYxtznKEHm92XQGf9c3/HyDpys4ZpcKkt9U7zQpMWfK2JDtxSEcxrlFsV8UkEWStjA 1QmW6el4Rm/q9JK2OYKdIdDmiWdgFJBWj5JILaZAlacg5Ax132yWJce7WSjd3pyQ+NnEIuLKVscQe 4dRhXjB8UBeetoiSbZ0MKXwDgoTQY5s2nLCkDNEblfiBiOR9mD5LHSMFgQZJrkgNJD8X/OBsQzlY1 zT7IIH5w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgUvJ-00000006Vkn-1OzY; Tue, 20 Aug 2024 19:53:45 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgUub-00000006Ve0-23m1 for linux-arm-kernel@lists.infradead.org; Tue, 20 Aug 2024 19:53:03 +0000 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-428e12f6e56so15095e9.0 for ; Tue, 20 Aug 2024 12:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724183579; x=1724788379; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=yp4vfYpCGOdYBS/m6HmbaB98zMN6C60AGpKXCWzp5n0=; b=mshwYhr3dOoyc3yhgyzadScx1D4M6zqawOKzqYljcENbxXrUDZW/QoHM926iPtLpRQ hhwVdNjMw6Qpl5w+p8vavtj+lw1aaEyUOWN9PeIQPC4Y3sRhIlSj/CyntR/kQWd4hi0B XDxE3qU3I/nNaR0hV4Qnqt6r36QT+tG8K10XGwB4T5aJUfhT6g4mZbtBErMMi4ElmUw/ Qzo4S+svr3feql1VLhA2Uyy0S4NAAVAw6gk7OThAIsoDvObQws2EjLE3wB5pSCKyU6fA lq64v8pOXCo31YLmar4fGawTAoldfzhoG7CMDhqJX3WL/fXVTSqwjtqxjahJm3OFeX8s ZJWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724183579; x=1724788379; h=in-reply-to:content-transfer-encoding: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=yp4vfYpCGOdYBS/m6HmbaB98zMN6C60AGpKXCWzp5n0=; b=sGDwmWRcfCncw5qIpGHO7OsFGdjGzzGXHrhh74JFuBxOSUyLiNTPaelpK46J8vhULz 3TIrJVzwUgGdhHzjVB5wGq6mlhlX2iE2mug2o6pGbsCxbHP/O7iOIpW/5ecaHPazPPMa X0+H3onkpB7RhfMCSoxmlu2lL5NPitqDt/EFTpDQ26i/UIN3dt8xKWEFuT+LGX7Ic82E G5nISTfJavYUuH6fZq9hqb7XI/UqLJnjatLp+ai2QHmqqQtNwIuoyxkoz28N48+liI/N 1zufh8Acm+Cj+jXDoiTFTdFyNbmYobg3dWYdJFSFvDmf7tGVD97uXX7aIQ3iBH7CYZkq Gkfg== X-Forwarded-Encrypted: i=1; AJvYcCX/2imqQ51vuVXawRB8qKuSQRgNs37FaV86AmX+mWnfcZUT5BxDySttsPyR98dyk2R0yjrz3FjOH15SFxXPRhIz@lists.infradead.org X-Gm-Message-State: AOJu0YzU7lOe2QY278Klcr40KFhKcyZgjjwUtGLy056Nt9dVDS1F+8zH oUlqrx/J//HrBNPK9vnMlinJEYh+7tQyhTYB596gGHGILfIVZQLvV9h56se96g== X-Google-Smtp-Source: AGHT+IEIPDf3d+uDL/Y/8Kxr91qxpv+48637k6O2srNTmFhDwf9KvmOeUX+rRg1Oapmp/C3vcKZSsw== X-Received: by 2002:a05:600c:1f07:b0:424:898b:522b with SMTP id 5b1f17b1804b1-42ab78c1aa8mr1113155e9.1.1724183578856; Tue, 20 Aug 2024 12:52:58 -0700 (PDT) Received: from google.com (203.75.199.104.bc.googleusercontent.com. [104.199.75.203]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-371898b89bdsm13811059f8f.112.2024.08.20.12.52.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Aug 2024 12:52:58 -0700 (PDT) Date: Tue, 20 Aug 2024 19:52:53 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: acpica-devel@lists.linux.dev, Alex Williamson , Hanjun Guo , iommu@lists.linux.dev, Joerg Roedel , Kevin Tian , kvm@vger.kernel.org, Len Brown , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lorenzo Pieralisi , "Rafael J. Wysocki" , Robert Moore , Robin Murphy , Sudeep Holla , Will Deacon , Eric Auger , Jean-Philippe Brucker , Moritz Fischer , Michael Shavit , Nicolin Chen , patches@lists.linux.dev, Shameerali Kolothum Thodi Subject: Re: [PATCH 2/8] iommu/arm-smmu-v3: Use S2FWB when available Message-ID: References: <0-v1-54e734311a7f+14f72-smmuv3_nesting_jgg@nvidia.com> <2-v1-54e734311a7f+14f72-smmuv3_nesting_jgg@nvidia.com> <20240820120102.GB3773488@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240820120102.GB3773488@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240820_125301_561232_162481ED X-CRM114-Status: GOOD ( 37.82 ) 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 20, 2024 at 09:01:02AM -0300, Jason Gunthorpe wrote: > On Tue, Aug 20, 2024 at 08:30:05AM +0000, Mostafa Saleh wrote: > > Hi Jason, > > > > On Tue, Aug 06, 2024 at 08:41:15PM -0300, Jason Gunthorpe wrote: > > > Force Write Back (FWB) changes how the S2 IOPTE's MemAttr field > > > works. When S2FWB is supported and enabled the IOPTE will force cachable > > > access to IOMMU_CACHE memory and deny cachable access otherwise. > > > > > > This is not especially meaningful for simple S2 domains, it apparently > > > doesn't even force PCI no-snoop access to be coherent. > > > > > > However, when used with a nested S1, FWB has the effect of preventing the > > > guest from choosing a MemAttr that would cause ordinary DMA to bypass the > > > cache. Consistent with KVM we wish to deny the guest the ability to become > > > incoherent with cached memory the hypervisor believes is cachable so we > > > don't have to flush it. > > > > > > Turn on S2FWB whenever the SMMU supports it and use it for all S2 > > > mappings. > > > > I have been looking into this recently from the KVM side as it will > > use FWB for the CPU stage-2 unconditionally for guests(if supported), > > however that breaks for non-coherent devices when assigned, and > > limiting assigned devices to be coherent seems too restrictive. > > kvm's CPU S2 doesn't care about non-DMA-coherent devices though? That > concept is only relevant to the SMMU. > Why not? That would be a problem if a device is not dma coherent, and the VM knows that and maps it’s DMA memory as non cacheable. But it would be overridden by FWB in stage-2 to be cacheable, it would lead to coherency issues. > The issue on the KVM side is you can't put device MMIO into the CPU S2 > using S2FWB and Normal Cachable, it will break the MMIO programming > model. That isn't "coherency" though.> > It has to be Normal-NC, which this patch does: > > https://lore.kernel.org/r/20240224150546.368-4-ankita@nvidia.com Yes, that also breaks (although I think this is an easier problem to solve) > > > But for SMMUv3, S2FWB is per stream, can’t we just use it if the master > > is DMA coherent? > > Sure, that seems to be a weird corner. Lets add this: > > @@ -4575,7 +4575,12 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) > > /* IDR3 */ > reg = readl_relaxed(smmu->base + ARM_SMMU_IDR3); > - if (FIELD_GET(IDR3_FWB, reg)) > + /* > + * If for some reason the HW does not support DMA coherency then using > + * S2FWB won't work. This will also disable nesting support. > + */ > + if (FIELD_GET(IDR3_FWB, reg) && > + (smmu->features & ARM_SMMU_FEAT_COHERENCY)) > smmu->features |= ARM_SMMU_FEAT_S2FWB; > if (FIELD_GET(IDR3_RIL, reg)) > smmu->features |= ARM_SMMU_FEAT_RANGE_INV; > > IMHO it would be weird to make HW that has S2FWB but not coherency, > but sure let's check it. > What I mean is the master itself not the SMMU (the SID basically), so in that case the STE shouldn’t have FWB enabled. > Also bear in mind VFIO won't run unless ARM_SMMU_FEAT_COHERENCY is set > so we won't even get a chance to ask for a S2 domain. Oh, I think that is only for the SMMU, not for the master, the SMMU can be coherent (for pte, ste …) but the master can still be non coherent. Looking at how VFIO uses it, that seems to be a bug? Thanks, Mostafa > > Jason