From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by dpdk.org (Postfix) with ESMTP id 374B79209 for ; Tue, 26 Jan 2016 11:26:52 +0100 (CET) Received: by mail-pa0-f54.google.com with SMTP id ho8so95831413pac.2 for ; Tue, 26 Jan 2016 02:26: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=f7cSsBB+qHR9O+LMyCH5A3Km4c7yj+juiQ/OFzaT9IY=; b=0goXMNxsWLiEjki1DjbVha/AHZzIVe9r7OyeStkoaKt6t2I4MWcBrLinPhDXl/8I3k 8Lh2EJgy3t/dKgs1I2be0Y51Rh/vMlsxIajwG8/6UKvVzBW4o4GXx9kgxtES3Atzd4bv Q9IMfuyjgbsYxnjPifExrC2MPr7LqNJ22ecnqYCPsL2WnIu+B9QEjSZ6o50500we9PJJ JU2K+GjtOXRsVYl69/zVovmMt8lnomNXGyfbLRpMplV2wauGcttvVWm2cpf0FhMQKJCp v7OCw/8jvvm7LNj+GKbh8G2XzlLS+71ubV/k71kCoHy7+PMDZk9cIBbXdF35ydlqEfXO H1gQ== 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=f7cSsBB+qHR9O+LMyCH5A3Km4c7yj+juiQ/OFzaT9IY=; b=MZZU+1D2wIvasPIGK0r7JIirVb+g2K2iVWr3hdUZ5MoKVP007Sf0oevpeMjteUS7+y 3CG2NVGSIgC6YytQm13prXTl6EkKzapbPJbDsNdao1OG2+7RP1UmU4rjgxtdsWyGqDUD KFYYAfLCD3FVrtzcK1QmoWUODC4cEU9fQ5ObN2WNFc3zKabu7/zZQD+TC6f4UTGk3YYv xm8bH7/N3/CSn96EhxOcV3p9LwsbUolPXEbE4ybnVIcIFJzHDZRuXUB3KTGsu+rFAByC AkEn873I8e6s13rL2XcioPEYZN98YYnr1kTYfSwolBUG/xyS8g6qt7ygKPqIG8nu47Zs Y/Mw== X-Gm-Message-State: AG10YORJVwFQLQafow3lh0SlBcAEApSa5+P6DAXKhXgE5zkNOL/YeAb4hd0kB1b1U7jP8TrFPmWyXIEfx4pNIAMB MIME-Version: 1.0 X-Received: by 10.66.182.202 with SMTP id eg10mr32928755pac.50.1453804011563; Tue, 26 Jan 2016 02:26:51 -0800 (PST) Received: by 10.66.196.81 with HTTP; Tue, 26 Jan 2016 02:26:51 -0800 (PST) In-Reply-To: <2661661.zCOWZL8G2B@xps13> References: <1453229842-15310-1-git-send-email-sshukla@mvista.com> <4435068.Ty9Jpve82j@xps13> <2661661.zCOWZL8G2B@xps13> Date: Tue, 26 Jan 2016 15:56:51 +0530 Message-ID: From: Santosh Shukla To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Cc: "Michael S. Tsirkin" , 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: Tue, 26 Jan 2016 10:26:52 -0000 On Mon, Jan 25, 2016 at 8:59 PM, Thomas Monjalon wrote: > 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" In my observation, currently virtio work for vfio-noiommu, that's why said drv->kdrv need to know vfio mode. > and after > "Those apis currently used for VFIO, Irrespective of vfio mode" > That's why I assume your first assumption was wrong. > Newly introduced dpdk global api pci_eal_rd/wr_bar(), can be used for vfio and uio both; can be used for vfio w/IOMMU and vfio w/o IOMMU both. >> >> > 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. > Interesting, like to understand nested one, I did tried in past by passing "iommu=pt intel_iommu=on kvm-intel.nested=1" in cmdline for x86 (for guest/host both), but virtio pci device binding to vfio-pci driver fails. Tried on 4.2 kernel (qemu version 2.5), is it working for >4.2 kernel/ qemu-version? >> 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. > with vfio+iommu; binding virtio pci device to vfio-pci driver fail; giving below error: [ 53.053464] VFIO - User Level meta-driver version: 0.3 [ 73.077805] vfio-pci: probe of 0000:00:03.0 failed with error -22 [ 73.077852] vfio-pci: probe of 0000:00:03.0 failed with error -22 vfio_pci_probe() --> vfio_iommu_group_get() --> iommu_group_get() fails: iommu doesn't have group for virtio pci device. In case of noiommu, it prepares the group / add device to iommu group, so it passes. Jason in other thread mentioned that he is working on virtio+iommu approach [1], Patches are not merged and I am yet to evaluate his patches for virtio pmd driver for iommu(+vfio). so wondering how virtio pci device could work unless jason patches used? [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg337079.html >> >> 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. > pci_vfio_is_noiommu() parses /sys for - enable_noiommu param - attached driver name is vfio-noiommu or not. It does file operation for that, I meant to say that calling this api within register_rd/wr function is not correct. It would be better if those low level register_rd/wr api only checks driver_types.