Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2752666yba; Mon, 6 May 2019 10:58:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqzC/INo5PSaF98bVxdOsByoWn7njPBXim7E2plt0OWbQAi2VhlmpTqm2Vw9XeSUhJe1nCFg X-Received: by 2002:aa7:9afc:: with SMTP id y28mr35326341pfp.101.1557165494262; Mon, 06 May 2019 10:58:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557165494; cv=none; d=google.com; s=arc-20160816; b=nQmuxRLvcsU3jTk3yBWwhUpZCGeQpob41TnOnNpGq2lQWWOuORKsqCClCIgY9S6xfV dp9h8PEcpElPH74M44/z6d22rDre28E9PnNJtCCAFfpvMyM1GZgWPZuNL1xVBMG4S56P pkyXzIAZ/uiAI2xcxcBbjWYDJPd5QujAs9lcuIoEs7pstwpQbgZXrTH9a7AG15FLNYOx OTI/BwOSVisnm4UL1V4E2/CnIiuVvOnahy/vrp1DDWjQEcIY+AgVDnw9m4T1r2sw0kz4 5pQ0XyUELISl15MoL2tFzPAviWyY2p4emIQK3ocKv/czG8hX7s7YUWVbzOgCRKYt/+G0 FquQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=XgcBPgF1G8mWsEvrlCrTStioPWUfDuKosdmWCCS6E5E=; b=UXnycCPTsoGTL5gMolHAst30vXXt04Cyoig6xC6qjVw5zCbIHlv+n3wGae3VIXIey5 6x9J6Ei+/JvZ0bBkhGbmAV8ztASPS4kbphrMKYb8EgrKhIvGY8Pjf/a4TYB9RPFIVMop hgOtph+eLLqRq8Lzg8vTIA8ENHq1Y3ZZU2p1QaPVDmB8gCIodoieBjILsmVACKHTXr55 75nCPnMiGWvlnTJjii6/2Jm8YB3YRFac4UUOKG5t6+ZehBD6Qym6bhuJrm1HSiSTjWbQ 4miokPp91nZS+MfUnTQngcMYiqU4Cqw0rX73elN72WMm7CwNdq8Csv94Omt5YDydnX5t 6Rig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@arista.com header.s=googlenew header.b=VTcOSw6D; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=arista.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k8si15895541pll.318.2019.05.06.10.57.58; Mon, 06 May 2019 10:58:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@arista.com header.s=googlenew header.b=VTcOSw6D; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=arista.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726942AbfEFR41 (ORCPT + 99 others); Mon, 6 May 2019 13:56:27 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:34631 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726591AbfEFR40 (ORCPT ); Mon, 6 May 2019 13:56:26 -0400 Received: by mail-wm1-f66.google.com with SMTP id m20so5961552wmg.1 for ; Mon, 06 May 2019 10:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XgcBPgF1G8mWsEvrlCrTStioPWUfDuKosdmWCCS6E5E=; b=VTcOSw6DyJHMGc0Los3OPWsCksrdPWPyD8vO7tfd4hoUYxYcfmFRvdg6+xhXohcDI4 iaPbQJh8VcU547wAZs36ZseUPhEx2n6IGa7dslufaoh80Vv9iPal8eujdbqhX47dUUCf rd0f8NtzfQWEGvOpMeRmdX8JSJP8cWcKcVhIbhptYXMtK+CkC+jkyMF1+0K9zUfHIWKS SJl54+i/RAyvIlSJFHmzstzMCaSBfFTRYRQj0rviMBg1ovVLt3DHD9KLbmEDFh5DQkUB K/4VUUv6V6l3X4JgKl9DsDvUKdy2qvZJaDBJBTVgKEAth7AkIIbN3tSX8f+DjWvOa5Un ZWlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XgcBPgF1G8mWsEvrlCrTStioPWUfDuKosdmWCCS6E5E=; b=j+xOvUTkABjrnDrQRNoQsoFkFz0ikh2rVdcfzPsDYtiLKJLRqAfp1Y0+SET5pUqW6Z ACRl7PqjBuvJSex3iW8p1FdHUo5NFwpSdtIIps2YA8o4cH9CBzQ1h1YJdbpJVAL565uX o3/sk1ZTihyWUzJ0vzaqWKypwb1Livp4/rJmzrhypoX2sab7chG7jo2Maf82diwSRvjQ +1ebIIcEfo1EvwRgk03DZR91Em05IKKVpdDllzAxMx8p2cs80S1yAwJUFT1vpcqRlUj0 WPYu049x6OExIQB5TwOV5lwDSYzjjZczvaH+xxXzKiepUtiZWzb8PH2EjRjgyxhnWcKR 7tiA== X-Gm-Message-State: APjAAAXsjBnA2BqefKwUU376nQ+hdegFWMV1cXNQPnO4lQ00qfpMR/+a 8KqX+iLwGsyPpMwecrEGsIbhWhS+YcrYhOheCNivBA== X-Received: by 2002:a1c:2e88:: with SMTP id u130mr10259976wmu.54.1557165384862; Mon, 06 May 2019 10:56:24 -0700 (PDT) MIME-Version: 1.0 References: <20190430002952.18909-1-tmurphy@arista.com> <20190430002952.18909-4-tmurphy@arista.com> <20190430111222.GA3191@infradead.org> <20190430113253.GA23210@infradead.org> <96ebb6fc-a889-fa94-09ba-65d505b85724@arm.com> In-Reply-To: <96ebb6fc-a889-fa94-09ba-65d505b85724@arm.com> From: Tom Murphy Date: Mon, 6 May 2019 18:56:13 +0100 Message-ID: Subject: Re: [PATCH v2 3/4] iommu/dma-iommu: Use the dev->coherent_dma_mask To: Robin Murphy Cc: Christoph Hellwig , iommu@lists.linux-foundation.org, Heiko Stuebner , Will Deacon , David Brown , Thierry Reding , linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, Krzysztof Kozlowski , Jonathan Hunter , linux-rockchip@lists.infradead.org, Kukjin Kim , Gerald Schaefer , Andy Gross , linux-tegra@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mediatek@lists.infradead.org, Matthias Brugger , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Tom Murphy , David Woodhouse Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Just to make this clear, I won't apply Christoph's patch (the one in this email thread) and instead the only change I will make is to rename dma_limit to dma_mask. On Tue, Apr 30, 2019 at 1:05 PM Robin Murphy wrote: > > On 30/04/2019 12:32, Christoph Hellwig wrote: > > On Tue, Apr 30, 2019 at 12:27:02PM +0100, Robin Murphy wrote: > >>> Hmm, I don't think we need the DMA mask for the MSI mapping, this > >>> should probably always use a 64-bit mask. > >> > >> If that were true then we wouldn't need DMA masks for regular mappings > >> either. If we have to map the MSI doorbell at all, then we certainly have to > >> place it at an IOVA that the relevant device is actually capable of > >> addressing. > > > > Well, as shown by the patch below we don't even look at the DMA mask > > for the MSI page - we just allocate from bottom to top. > > In the trivial cookie for unmanaged domains, yes, but in that case the > responsibility is on VFIO to provide a suitable (i.e. sub-32-bit) > address range for that cookie in the first place. In the managed case, > allocation uses the streaming mask via iommu_dma_get_msi_page() calling > __iommu_dma_map(). Admittedly the mask can then get overlooked when > reusing an existing mapping, which strictly could pose a problem if you > have multiple devices with incompatible masks in the same group (and > such that the PCI stuff doesn't already mitigate it), but that's such an > obscure corner case that I'm reticent to introduce the complication to > handle it until it's actually proven necessary. > > Robin.