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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_HIGH autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB2D1C04A6B for ; Mon, 6 May 2019 17:56:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B558E20830 for ; Mon, 6 May 2019 17:56:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=arista.com header.i=@arista.com header.b="VTcOSw6D" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726979AbfEFR41 (ORCPT ); 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-Google-Smtp-Source: APXvYqy6O9Hx4Xu6PpK27h5ZvwKOZrtRiCBaX5D6FeKqa43xpsoBRLSUcAf7GCThq5ov8PH4U8Kpn29YDNsu9mBVmhc= 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.