From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id 156938E94 for ; Thu, 21 Jan 2016 18:17:45 +0100 (CET) Received: by mail-pf0-f181.google.com with SMTP id e65so26705786pfe.0 for ; Thu, 21 Jan 2016 09:17:45 -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=hR3RZuroa/0+3+MSjXgXqkooMA4iVCbqI0ucPK0WWA8=; b=jV+yWzDIPRwkUu/ixALL1KM1OEz+nDNgby+AwwauGxLjFYKdighymQqsIuCuTnoXLM MAgcBfmdDxLOm1l2v41cuiNDH/24SQDERdMQaE29RGpqcmuecH53wX2GEo0YgdftuOnj bI4Yb3T4B77xyNtCJnvgzarj/yk0ET1tXYvcgx2KS5iAF82jXEAXZhe+oDupD/VnynoR ds/e1vwCsUcuCZ2+A3n66onDsf+PeeCprf2emkGDwelD4ylSdNMkK8muj5b8ZSNcn2qv khZ12UcVYtL9eZgwdrPc2pLnmMaogHgLFRn1gX4RF6iiQedn/zk9k06UBKEuaWR11Qg7 RQwQ== 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=hR3RZuroa/0+3+MSjXgXqkooMA4iVCbqI0ucPK0WWA8=; b=i6VtrDERpfokEJXRVGgQVKj9zqq/pikTu5NGSjAd/iytgJzXM4FITsrcPf9BaIELHZ xejFw3VECe11Ld1ntQJnhS1ckl0V9IU8bpcNYM8aM1YtC/fzYAWsIYhWXruu4jHbbYQU bosadV2b/23vPHFXZOjj5Y4b0ZYW90Hh0er5kioAKkmyHCVDiK53ZNPOtUdQJ1k5GKkG 0jJX3I7BR0c8rRiFJ19zBf/XshRuJ2fLTqiEvCXLRWLubvSQU35w/DbCXqYQu/B4MFSG s4bI2zeop9YoVw6GWb6QjDunmrmS0SrT0SdWN7IsrQMRZPpIazr9koodla14tIORE7cL sgjQ== X-Gm-Message-State: ALoCoQln6MsxSThRDHX069XT1nt/oEVohdpsF5SMxF25Ey77Fcv+kzaUWzP8M/dznlvJ9mkovLj0EXg0oX+Fwwd2w3PDRZqZUb0vcTrBpUlFB3UEw20YF6Y= MIME-Version: 1.0 X-Received: by 10.98.12.131 with SMTP id 3mr63362142pfm.155.1453396664252; Thu, 21 Jan 2016 09:17:44 -0800 (PST) Received: by 10.66.196.81 with HTTP; Thu, 21 Jan 2016 09:17:44 -0800 (PST) In-Reply-To: <4435068.Ty9Jpve82j@xps13> References: <1453229842-15310-1-git-send-email-sshukla@mvista.com> <1491599.cgkG2mIphR@xps13> <4435068.Ty9Jpve82j@xps13> Date: Thu, 21 Jan 2016 22:47:44 +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 17:17:45 -0000 On Thu, Jan 21, 2016 at 8:16 PM, Thomas Monjalon wrote: > 2016-01-21 17:34, Santosh Shukla: >> 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. > > Sorry I don't understand. Why EAL read/write functions should be different > depending of the VFIO mode? > no, EAL rd/wr functions are not different for vfio or vfio modes {same for iommu or noiommu}. Pl. see pci_eal_read/write_bar() api. Those apis currently used for VFIO, Irrespective of vfio mode. If required, we can add UIO bar_rd/wr api too. pci_eal_rd/wr_bar() are abstract apis. Underneath implementation can be vfio or uio type. >> 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. > > Please could you explain the limitation (except IOMMU availability)? > Ok. I believe - we both agree that noiommu mode is a need for pmd drivers like virtio, right? if so then other reason is implementation driven i.e.. Pl. look at virtio_pci.c in this patch.. VIRTIO_RD/WR/_1/2/4() implementation. They are in-use and applicable to virtio spec 0.95, so far support uio/ioport-way rd/wr. Now to support vfio-way rd/wr - need to check drv->kdrv value, that value should be of vfio_noiommu types __not__ generic _vfio types. >> 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. > > If a check is needed, I would prefer using your function > pci_vfio_is_noiommu() and remove driver modes from struct rte_kernel_driver. > I don't think calling pci_vfio_no_iommu() inside virtio_reg_rd/wr_1/2/3() would be a good idea. >> 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/ > > Yes he said > "we should try to avoid getting UIO/VFIO stuff inside virtio pmd driver". > I agree we must try to have those abstractions in EAL. Right, IMO vfio now has that abstraction in place and pmd driver only to check driver type, which virtio-net pmd doing for vfio case. ` > The only exception seems to be the switch ioport/PCI bar to read/write > in virtio. > Right, and only applicable for x86 arch, wont work for non-x86 archs. >> > 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. > > So you agree that the VFIO API abstract the iommu availability details? > didn't understood your question, >