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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,URIBL_SBL,URIBL_SBL_A, USER_AGENT_SANE_1 autolearn=no 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 9B322C606B0 for ; Tue, 9 Jul 2019 09:44:42 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 5AF2321670 for ; Tue, 9 Jul 2019 09:44:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5AF2321670 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 027034C94; Tue, 9 Jul 2019 11:44:41 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 17B64493D for ; Tue, 9 Jul 2019 11:44:38 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 02:44:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,470,1557212400"; d="scan'208";a="165717083" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.82]) ([10.237.220.82]) by fmsmga008.fm.intel.com with ESMTP; 09 Jul 2019 02:44:36 -0700 To: Jerin Jacob Kollanukkaran , David Marchand Cc: dev , Thomas Monjalon , Ben Walker References: <20190708142450.51597-1-jerinj@marvell.com> From: "Burakov, Anatoly" Message-ID: Date: Tue, 9 Jul 2019 10:44:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: fix IOVA as VA mode selection X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 08-Jul-19 8:13 PM, Jerin Jacob Kollanukkaran wrote: > See below, > > Please send the email as text to avoid formatting issue.(No HTML) > > From: David Marchand > Sent: Tuesday, July 9, 2019 12:09 AM > To: Jerin Jacob Kollanukkaran > Cc: dev ; Thomas Monjalon ; Ben Walker ; Burakov, Anatoly > Subject: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: fix IOVA as VA mode selection > > ________________________________________ > > On Mon, Jul 8, 2019 at 4:25 PM wrote: > From: Jerin Jacob > > Existing logic fails to select IOVA mode as VA > if driver request to enable IOVA as VA. > > IOVA as VA has more strict requirement than other modes, > so enabling positive logic for IOVA as VA selection. > > This patch also updates the default IOVA mode as PA > for PCI devices as it has to deal with DMA engines unlike > the virtual devices that may need only IOVA as DC. > > We have three cases: > - driver/hw supports IOVA as PA only > > [Jerin] It is not driver cap, it is more of system cap(IOMMU vs non IOMMU). We are already addressing that case I don't get how this works. How does "system capability" affect what the device itself supports? Are we to assume that *all* hardware support IOVA as VA by default? "System capability" is more of a bus issue than an individual device issue, is it not? -- Thanks, Anatoly