Received: by 10.223.164.221 with SMTP id h29csp1919698wrb; Fri, 6 Oct 2017 09:17:45 -0700 (PDT) X-Google-Smtp-Source: AOwi7QB4GXgnvLvzze4ilyPt6SioL6efK5vL06wigQtDAHFYGdrg2zPTB5U1RVbUGdD4qNbXRmZx X-Received: by 10.101.81.1 with SMTP id f1mr2525834pgq.204.1507306664956; Fri, 06 Oct 2017 09:17:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507306664; cv=none; d=google.com; s=arc-20160816; b=WZL4Aido+r9S6SPTgWzmy5aYe9YQgxKcPYJc2YWJgQAlCzolvGMEzh4LYqE/1PFJ5L EMjI28BL8TcBi59Gu8UHKyrDvcjvWCRLu4LvCnlxNZLVwgT2unPcV7DyNKso++dAGnLy MYxY9/n8do5r+Dg/9SbWJf7PFcSQmnCaLICgGZzCNweNqZgw5MqQwhlNlCfS6jKgepe+ yE3mtS0/xkRLRocnv+fxdcq5HE7Ojf0eOqKGYLst9yRvRzOh2z5AuDWTtkU7ZF25SdA+ 8ola6DW93l+YiMjKr0RlvqjbVSCy7EQNwOcyjTmz8e/XpDS3wxsXpSHKueYZisx+WThJ 4PXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Trw6YrnIzA2gy2GedoKgJrUctWm24qwj0H3WrWXG6WM=; b=MFa2tyRAUJSuhudUeJiT3NJKld0LGLfkIrp3owqTMtToDZI7xOawAiBl3C9DwKIF+K frgT7XmuHUiZUaVvF2SLgnNOAhH9MsnjWwt6maVzTk55NbNCeec5nDnVwuGYnlnzciyH 4erVoTjzjHBEko9XTWZqXESvQlmbMewh/MZAl4Mh4u4TsDxv6Kp5IpbLGJIIt1SC//t2 xBMbvVwNxXzehPUOP7j2KcZdOl+aoBWBQbScDw2Y/wiE/hboOZgz1Hbx/0w5Z+04Z+Ou K0VlyDYyJ9eBI/CEPydc2VKRz60Iz1EBzKwaLSEc0yYvaNJNMtiqj179ejLKmCq9YpCm bqyg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h186si191456pfg.480.2017.10.06.09.17.28; Fri, 06 Oct 2017 09:17:44 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbdJFQRD (ORCPT + 99 others); Fri, 6 Oct 2017 12:17:03 -0400 Received: from mga14.intel.com ([192.55.52.115]:64875 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbdJFQRC (ORCPT ); Fri, 6 Oct 2017 12:17:02 -0400 Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2017 09:17:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,484,1500966000"; d="scan'208";a="135950487" Received: from otc-nc-03.jf.intel.com (HELO otc-nc-03) ([10.54.39.37]) by orsmga004.jf.intel.com with ESMTP; 06 Oct 2017 09:16:55 -0700 Date: Fri, 6 Oct 2017 05:54:29 -0700 From: "Raj, Ashok" To: Joerg Roedel Cc: Robin Murphy , David Woodhouse , leedom@chelsio.com, Harsh@chelsio.com, herbert@gondor.apana.org.au, iommu@lists.linux-foundation.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling Message-ID: <20171006125428.GA258394@otc-nc-03> References: <644c3e01654f8bd48d669c36e424959d6ef0e27e.1506607370.git.robin.murphy@arm.com> <1507035334.29211.105.camel@infradead.org> <20171006144309.GA30803@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171006144309.GA30803@8bytes.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 06, 2017 at 04:43:09PM +0200, Joerg Roedel wrote: > On Tue, Oct 03, 2017 at 07:05:17PM +0100, Robin Murphy wrote: > > Now, there are indeed plenty of drivers and subsystems which do work on > > lists of explicitly single pages - anything doing some variant of > > "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I > > don't think DMA API implementations are in a position to make any kind > > of assumption; nearly all of them just shut up and handle sg->length > > bytes from sg_phys(sg) without questioning the caller, and I reckon > > that's exactly what they should be doing. > > I agree with that, it is not explicitly forbidden to have an > sg->offset > PAGE_SIZE and most IOMMU drivers handle this case. > > So this is a problem I'd like to see resolved in the VT-d driver too. If > nobody comes up with a correct fix soon I'll apply this one and rip out > the large-page support from __domain_mapping() to make it work. That seems like a good start. I have reviewed Robin's fix and it seems to make sense. I'll start looking at making __domain_mapping() to make it more manageable. > > Speaking of __domain_mapping(), this function is a big unmaintainable > mess which should be split and rewritten. A clean and maintainable > rewrite can alse re-add the large-page support. > > > Regards, > > Joerg > From 1580519685599825798@xxx Fri Oct 06 14:43:50 +0000 2017 X-GM-THRID: 1579793157804914964 X-Gmail-Labels: Inbox,Category Forums