From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id D3B4B95CE for ; Tue, 2 Feb 2016 05:30:36 +0100 (CET) Received: by mail-pf0-f180.google.com with SMTP id n128so95175652pfn.3 for ; Mon, 01 Feb 2016 20:30:36 -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=Be5hDV29D/68WaOTmWQw8lKRcm7TO95sY7bROjLkL4w=; b=llxXjId3KwhIEQNK88Y+E6p9dNa9YiiwOLGMLwIzHTCly195uxG6TMGWB1clfWqwT7 Ry+SDOW+szyQDlWXTlXYURfP/mC+XB9SD3NEHXsoJqRhvV4VB+yODQOwvRFe+r+qncUs JvtY64cdOQN6tAkjJh4n9bZSPZ8pLqe+LQhyAskX+6vIxuGPHSz73O9spaog5iAwuFkE YynfWMKmzXJvlg09gLT4WH5dzd+/JbVXvNdeJXZolvADS7tK5VnK+QsqjEnvsZ5eiKIK PUY5RFOGWtuEMUZTpObNfPnWblnFZ08jSZpBdjgyjQ3b0PfAsJN+cFqKPt367+ARJY8r RrPQ== 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=Be5hDV29D/68WaOTmWQw8lKRcm7TO95sY7bROjLkL4w=; b=GPMrtIzHKNxJuS7FSgMr8W/MABIMXzJ78LmgLnQnRH6UEYOQG7aMh1dKej7sVz5d+l iiPZYEESPSIgStyYyyg3Bprbtv834i+7OzF2Dm1PX8ATLwkUT5Zqj0nUYVzMybPzl96f MCjNDTbQLmdmNzKVQr7yi4RCqTJs0vjqAXDh6rNFPj7bA9RbnCVFVU/5HEDR5IZiWfV1 S9Q0N1tyBMo31t3SQS6mnFVy4/vhNvNBd8DLM+Ag/fFJFgQIlY9EcNPCKPuizOIq+45R HYqQOCFS+oUvQ8S1xq6ItijE4oHKqnMWg/6DGoQnpSZm37iDYCWJwgZUGyro+4E3UBGx i6eA== X-Gm-Message-State: AG10YOQXnZclqjLdUceShMK5nwgHYAmEJyYWTi8z6cBx5ZSWiXjT6nnsn7oZ2TxUy1612UNE2WOxL7DQ/awtNDkr MIME-Version: 1.0 X-Received: by 10.98.42.81 with SMTP id q78mr43672052pfq.142.1454387436205; Mon, 01 Feb 2016 20:30:36 -0800 (PST) Received: by 10.66.12.132 with HTTP; Mon, 1 Feb 2016 20:30:36 -0800 (PST) In-Reply-To: <20160201124845.GC4257@yliu-dev.sh.intel.com> References: <1454091717-32251-1-git-send-email-sshukla@mvista.com> <1454091717-32251-6-git-send-email-sshukla@mvista.com> <20160201124845.GC4257@yliu-dev.sh.intel.com> Date: Tue, 2 Feb 2016 10:00:36 +0530 Message-ID: From: Santosh Shukla To: Yuanhan Liu Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org, Rakesh Krishnamurthy , Rizwan Ansari Subject: Re: [dpdk-dev] [PATCH v6 6/8] virtio: add vfio api to rd/wr ioport space 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, 02 Feb 2016 04:30:37 -0000 On Mon, Feb 1, 2016 at 6:18 PM, Yuanhan Liu wrote: > On Fri, Jan 29, 2016 at 11:51:55PM +0530, Santosh Shukla wrote: >> For vfio case - Use pread/pwrite api to access virtio >> ioport space. >> >> Signed-off-by: Santosh Shukla >> Signed-off-by: Rizwan Ansari >> Signed-off-by: Rakesh Krishnamurthy >> --- >> v5-->v6: >> - renamed inport_in/out to vfio_in/out >> - Renamed file from virtio_vfio_rw.h to virtio_vfio_io.h >> >> drivers/net/virtio/virtio_vfio_io.h | 104 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 104 insertions(+) >> create mode 100644 drivers/net/virtio/virtio_vfio_io.h >> >> diff --git a/drivers/net/virtio/virtio_vfio_io.h b/drivers/net/virtio/virtio_vfio_io.h >> new file mode 100644 >> index 0000000..218d4ed >> --- /dev/null >> +++ b/drivers/net/virtio/virtio_vfio_io.h > ... >> @@ -0,0 +1,104 @@ >> +#ifndef _VIRTIO_VFIO_IO_H_ >> +#define _VIRTIO_VFIO_IO_H_ >> + >> +#include "virtio_logs.h" >> +#if defined(RTE_EAL_VFIO) && defined(RTE_LIBRTE_EAL_LINUXAPP) > Yes, Now that we have pci_eal_read/write_bar() dummy implementation for freebsd so we don't need both checks. I overlooked it, sending v7 for this patch now. Thanks. > Won't it cause build failure if above "#if ..." is false, as > virtio_read/write_reg_x() reference them unconditionally? > > BTW, why above check is needed? We have rte_eal_pci_read/write_bar() > implementation with both VFIO and BSD, don't we? > > >> +#endif /* _VIRTIO_VFIO_RW_H_ */ > ^^^^ > You forgot to do rename here. > My bad (:- > > BTW, I didn't follow the noIOMMU discussion; how did it end? Do we still > need that? Is this patch a full story to enable virtio on ARM? > Ok, We agreed that explicit __noiommu suffix not required, atleast for rte_xx_drv struct{}, as because sooner than later we'll have virtio working for both flavours ie... iommu/noiommu. My only worry was parsing for _noiommu and default vfio case, as because noiomu needed user to preset "enable_noiommu_" param for vfio driver to do mode switch. But we wont need that parsing as because if param is not set then binding won't happen, which Thomas rightly pointed out, therefore I choose to drop resource parsing for virtio-for-vfio case, now virtio driver to check only drv->kdrv == RTE_KDRV_VFIO so to make sure interface attached to vfio or not. But perhaps when we have both flavours working for virtio, then we should at least prompt a INFO message on console that virtio pmd driver attached to default vfio or noIOMMU. So we don't need explicit _noIOMMU. Yes this patch is to enable non-x86 arch to use virtio pmd driver (virtio 0.95 spec). After this patch merges-in, I am planning to - replace sys/io.h entirely - Add raw_read/raw_writel() api for arm/arm64 {Already proposed similar implementation in v2} so that they could use virtio 1.0spec mapped memory, for both UIO/VFIO mode.