From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7E5BEA046B for ; Tue, 23 Jul 2019 16:29:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 508D91C030; Tue, 23 Jul 2019 16:29:56 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id A23181C02F for ; Tue, 23 Jul 2019 16:29:54 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 07:29:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,299,1559545200"; d="scan'208";a="174560103" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.83]) ([10.237.220.83]) by orsmga006.jf.intel.com with ESMTP; 23 Jul 2019 07:29:52 -0700 To: Thomas Monjalon Cc: Jerin Jacob Kollanukkaran , "Stojaczyk, Dariusz" , David Marchand , "dev@dpdk.org" References: <1562795329-16652-1-git-send-email-david.marchand@redhat.com> <3397bb38-115b-40e8-c208-006fa5dd7405@intel.com> <1862469.LujG46irEj@xps> <751d0163-ed33-e05b-dd24-386055114384@intel.com> From: "Burakov, Anatoly" Message-ID: <3e82b693-6680-ee0d-b5cb-4f2e881e6ba3@intel.com> Date: Tue, 23 Jul 2019 15:29:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <751d0163-ed33-e05b-dd24-386055114384@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA 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 23-Jul-19 2:56 PM, Burakov, Anatoly wrote: > On 23-Jul-19 11:25 AM, Thomas Monjalon wrote: >> 23/07/2019 11:57, Burakov, Anatoly: >>> A machine without an IOMMU shouldn't have picked IOVA as VA in the first >>> place. Perhaps this is something we could fix? I'm not sure how to >>> detected that condition though, i don't think there's a mechanism to >>> know that for sure. Some kernels create a "iommu" sysfs directories, but >>> i'm not too sure if they're 1) there for older kernels we support, and >>> 2) always there. >> [..] >>> On my machine, "/sys/devices/virtual/iommu" exists when IOMMU is >>> enabled, but doesn't exist if it isn't ("/sys/class/iommu" exists in >>> both cases, but is empty when IOMMU is disabled). Perhaps we could go >>> off that? >> >> Yes, good idea. >> We need to check how these sysfs entries are managed, >> and how old they are by looking at Linux code history. >> > > Quick (and by no means thorough) Google reveals that IOMMU driver's > sysfs-related code dates back as far as kernel version 3.17: > > https://elixir.bootlin.com/linux/v3.17.8/source/drivers/iommu/iommu-sysfs.c > > I'm not a kernel code expert, but the code *looks* like it's creating an > IOMMU-related entry in sysfs. So, i take it we can be reasonably sure of > these entries' presence at least since v3.17 onwards? Do we support > kernels which don't have this code? > After a short chat with Ferruh, i think we have even better way to determine whether IOMMU is enabled - the /sys/kernel/iommu filesystem. Those are created whenever it is possible for VFIO to run, even if VFIO driver itself is not loaded. These have been there since kernel 3.6, so our minimum requirements are met with this approach, i believe. -- Thanks, Anatoly