From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id EFDC4379E for ; Thu, 21 Jan 2016 13:04:52 +0100 (CET) Received: by mail-pa0-f46.google.com with SMTP id yy13so22297503pab.3 for ; Thu, 21 Jan 2016 04:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xMxBSmSiTWzEB8G8WWnW1jGmLLMxloxh6COCv1J3tG0=; b=N7SatUol/579HWe8qlVVSPefq6winzNS8CelrddkVa298iGdyfRku6yl7jZkXZKZo9 NtYUAYhaKYZJczZVsc6IehfkjvXJIuedEwcZcHRf7XT0avx8aWj6imZmricGjrkIx9JI DKfeT5EkRqMIKhKZWQnlPUCrAs/MA2bYE1vt2fhxU7s8xKs9kjTQDslUO6d8zR0KMCBu 6ekxio2TOzQ6XrbLNYsfDesCToi9UyteRMhpGyqHEko0QO3cKNw5/9zx7V1QadGed/MJ lQK2JmLIPD/JNbsbnqWQfE5nD9iSWGCYoDrWO1TAOeTFjTjflB9GT3mVgovLjB5pENnr hLrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xMxBSmSiTWzEB8G8WWnW1jGmLLMxloxh6COCv1J3tG0=; b=UgnsavXuaKbKRx+m9GZKLlvcGCkFcWyExVXKReV1EGPJ+QLb0U8DHSOMnTNGJeGd/H /fa8k/sCEYyn+1/ysxlmo/04Eba02XamxG9PkPQBUX67Znz9gWEqjZZYhvGo5xvshPhE bkjGXG8v2kvTYlHfIG8GDsYnRwLLQ3AeAzqmJz2g4i8ghVLBzqVmsJiK+KG/O7KpWntY 1L4FRDB2YcrSOXh3+mULA0JGqGqAusi+We88JW36VH/F+/Q9GiKw49jGgaAUOA+H+jRC gRUqCuCG7XcO+LI9KVswoquM2ZgqM1kqpZ/WNKJ8vMqaZXt55uwmXGn/eyCTesXhTY5v BHGA== X-Gm-Message-State: ALoCoQloBHGmhioq9vakCMOZgVRAeZAqNfohak7KuXYNW4+nZbQm0aiKBOIUh3W0+tNMY+Z7ks1KBkJU7rQ9Wzqxjz3KfAgQAMA9i1Z4BNt4bnX1uJFTYHY= MIME-Version: 1.0 X-Received: by 10.66.182.202 with SMTP id eg10mr60622687pac.50.1453377892348; Thu, 21 Jan 2016 04:04:52 -0800 (PST) Received: by 10.66.196.81 with HTTP; Thu, 21 Jan 2016 04:04:52 -0800 (PST) In-Reply-To: <1491599.cgkG2mIphR@xps13> References: <1453229842-15310-1-git-send-email-sshukla@mvista.com> <1491599.cgkG2mIphR@xps13> Date: Thu, 21 Jan 2016 17:34:52 +0530 Message-ID: From: Santosh Shukla To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org, Alex Williamson Subject: Re: [dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:04:53 -0000 On Thu, Jan 21, 2016 at 4:58 PM, Thomas Monjalon wrote: > 2016-01-21 16:43, Santosh Shukla: >> David Marchand 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). > I am confused by reading your comment. vfio works for default iommu and now with noiommu. drv->kdrv need to know driver mode for vfio case. So that user can simply read drv->kdrv value in their driver and accordingly use vfio rd/wr api for example {pread/pwrite}. This is how rte_eal_pci_vfio_read/write_bar() api implemented. And Yes it is called VFIO but with with specifics appended in it. >> > 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? Because pmd drivers example virtio can work with vfio only in _noiommu_ mode. In particular, virtio spec 0.95 / legacy virtio. So at the initialization (example .. virtio-net) of such pmd driver, pmd driver should know that vfio-with-noiommu mode enabled or not? for that pmd driver simply checks drv->kdrv value. Currently virtio-net pmd driver does resource parsing then resource init for interfaces like UIO/ioport, I intend to do same but only parsing, as resource init for vfio case already taken care by pci_xx_vfio_map() api in virtio-net pmd driver (refer Yaun recently virtio 1.0 recently submitted rte_eal_pci_map patch) Also Yuan in one of earlier thread inclined to remove all the resource parsing api from virtio-net pmd driver. Pl. refer this thread [1] [1] http://dpdk.org/dev/patchwork/patch/9862/ > 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. vfio apis _are_ considered at low level rd/wr implementation, Has nothing to do with iommu/noiommu mode. See pci_vfio_read/write_bar() implementation, they are using pread64/pwrite64() vfio rd/wr api.