From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 209957F6D for ; Mon, 25 Jan 2016 16:30:10 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id r129so68815522wmr.0 for ; Mon, 25 Jan 2016 07:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=aEQWS+s3QN7RnFPziRzO0apj/+FDNtwOTjL02OCxoqs=; b=Wi8YgJrVecxPShx8ob8j3vENFEWzxwqEmsLyUyEtytfzeQzvg22X392PV0B3WSyFy0 tcxI52yYh3SmUW4oZDfEDAxmrEJtcrq/lng0XhSmQ4iiOwt8juwHk+S6G1ndg6o29hzN CY7oiLo9vi9IIpGEa0J8XWU2FW/il1KyTemJASZqedeiK76OCKRVvy4Qmoih3Syv0NI7 LUJ/pqONGLWqKaDmSMI+cIdGggfTxcm698bC5XrnKKLgwD9VQjwky0qhfZQ0LFBDCZOQ QZ9Fob8sbSzceyEBJITWIfblHEsaGBIbBTu89TpIi1Z6mK0C4h9CjnyLsEJHRrRbX6dq 715g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=aEQWS+s3QN7RnFPziRzO0apj/+FDNtwOTjL02OCxoqs=; b=A/xEJ0o0uLhudo+SHhhbX8HBfLSFis+Ndpg8SCV+rFp4ficG/1CW4GAbzDUONS9PSL PWa5maYcYqXXQkRIglDeYoiqXGGZDoW661aiTDuyV/ftY5CvSFua7XkTUnS90jdIOXpp r0SraHFXQ2o4I0rkFQjWSYLWDhyvc89+puRnabpROAVMDn8q1L/F4BKAGWrry30wluGU kBwlkDUFgQkyh2lijrzKdnPHFaKJJLn060Ksg/L82YNZIETmZCNCER1EWrNHUAEG4D4f +rAvPMeP7ijEgd9LdrbnMNimvY7FmdUmAbF2pdIijP3ZhWtOwbszVziYBnwQc2WR872o vfqA== X-Gm-Message-State: AG10YOShUqqAWUrNDX4X2fNOd+N//uVA476X4dMUstC+0iWYoXlN0YR1yZIndBFXJD3QPKUz X-Received: by 10.194.19.164 with SMTP id g4mr18001999wje.120.1453735809883; Mon, 25 Jan 2016 07:30:09 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id c185sm16736440wma.5.2016.01.25.07.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 07:30:08 -0800 (PST) From: Thomas Monjalon To: Santosh Shukla Date: Mon, 25 Jan 2016 16:29:03 +0100 Message-ID: <2661661.zCOWZL8G2B@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1453229842-15310-1-git-send-email-sshukla@mvista.com> <4435068.Ty9Jpve82j@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Mon, 25 Jan 2016 15:30:10 -0000 2016-01-21 22:47, Santosh Shukla: > 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. It means you agree the suffix _NOIOMMU is not needed? It seems we go nowhere in this discussion. You said "drv->kdrv need to know driver mode for vfio" and after "Those apis currently used for VFIO, Irrespective of vfio mode" That's why I assume your first assumption was wrong. > >> > 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 No, noiommu is a need for some environment having no IOMMU. But in my understanding, virtio could run with a nested IOMMU. > 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. I still don't understand why it would not work with VFIO w/IOMMU. > >> 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. Why? The value may be cached in the priv properties.