From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v6 08/11] eal: pci: introduce
	RTE_KDRV_VFIO_NOIOMMUi driver mode
Date: Thu, 21 Jan 2016 12:28:34 +0100
Message-ID: <1491599.cgkG2mIphR@xps13>
References: <1453229842-15310-1-git-send-email-sshukla@mvista.com>
 <CALwxeUvpghmk11YHCiGaRjDNfowJfLMTVWCGF9vLRrOZVQ4yHg@mail.gmail.com>
 <CAAyOgsZYiPjiKR6nfL8bEoyr5JnVXK3uuKCSsZYfNfDz=jU4Eg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, Alex Williamson <alex.williamson@redhat.com>
To: Santosh Shukla <sshukla@mvista.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
 by dpdk.org (Postfix) with ESMTP id BB8468E7B
 for <dev@dpdk.org>; Thu, 21 Jan 2016 12:29:35 +0100 (CET)
Received: by mail-wm0-f52.google.com with SMTP id 123so170042011wmz.0
 for <dev@dpdk.org>; Thu, 21 Jan 2016 03:29:35 -0800 (PST)
In-Reply-To: <CAAyOgsZYiPjiKR6nfL8bEoyr5JnVXK3uuKCSsZYfNfDz=jU4Eg@mail.gmail.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-01-21 16:43, Santosh Shukla:
> David Marchand <david.marchand@6wind.com> wrote:
> > This is a mode (specific to vfio), not a new kernel driver.
> >
> Yes, Specific to VFIO and this is why noiommu appended after vfio i.e..
> __VFIO and __VFIO_NOIOMMU.

Woaaa! Your logic is really disappointing :)
Specific to VFIO => append _NOIOMMU
If it's for VFIO, it should be called VFIO (that's my logic).

> > How come we need to distinguish between with/without iommu modes ?
> 
> By default vfio framework assumes iommu i.,e., iommu present. Unless user
> explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we
> care to parse vfio driver for _noiommu_ mode only.

Why do we care to parse noiommu only?
Even if virtio cannot work in an IOMMU case, there is no reason to add
a VFIO_NOIOMMU type here.

> > Should not vfio behave the same way from an api point of view ?
> >
> Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc..
> I am little confused on your question, do you see any issue in vfio bar
> rd/wr api implementation?

I think you should just consider the VFIO API and let the noiommu option
as a kernel configuration detail.