From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 1B0A52BA8 for ; Fri, 29 Apr 2016 15:46:19 +0200 (CEST) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3qxFNB5Z0vz7Jn; Fri, 29 Apr 2016 15:46:18 +0200 (CEST) From: Jan Viktorin To: dev@dpdk.org Cc: Jan Viktorin , Anatoly Burakov , David Marchand , Keith Wiles , Santosh Shukla , Stephen Hemminger Date: Fri, 29 Apr 2016 15:44:01 +0200 Message-Id: <1461937456-22943-1-git-send-email-viktorin@rehivetech.com> X-Mailer: git-send-email 2.8.0 Subject: [dpdk-dev] [PATCH 00/15] Make VFIO support independent on PCI 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: Fri, 29 Apr 2016 13:46:19 -0000 Hello, here follows several patchs extracting the general VFIO code out of the PCI + VFIO code base. Usually, it's just move and rename of functions. The most complicated ones are: * eal/linux: extract setup logic out of pci_vfio_map_resource - separation of some setup code out of the pci_vfio_map_resource (which is otherwise quite PCI-speicific) - it is required by the following one * eal/linux: move global vfio_cfg to eal_vfio.c - moving the vfio_cfg global variable out of the eal_pci_vfio together with the functions working with this variable Some patchs make just temporary changes to avoid breakages throughout the patch set (dma mapping). I am not sure, how exactly is the mp_sync code intended to work. Should there be just a single socket connection (no matter how many bus-systems we support)? I assume it works this way so I've generalized the eal_pci_vfio_mp_sync. The vfio initialization is moved out of the rte_eal_pci_init into EAL. The code is now prepared for adding of other infrastructures such as the SoC that I've introduced in [1]. I've partially done this in my workspace. The VFIO code is quite complex and written in a spaghetti style so a more maintainance would be helpful. I've did my best to preserve the semantics (I hope) to be 100 % the same as before. Important: I didn't test whether it's working as I have no VFIO-enabled machine at the moment and the SoC infra is not so ready yet. [1] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/30913 Regards Jan --- Jan Viktorin (15): vfio: fix include of eal_private.h to be local vfio: move VFIO-specific stuff to eal_vfio.h vfio: move common vfio constants to eal_vfio.h vfio: move vfio_iommu_type and dma_map functions to eal_vfio vfio: generalize pci_vfio_set_iommu_type vfio: generalize pci_vfio_has_supported_extensions vfio: move vfio-specific SOCKET_* constants vfio: generalize pci_vfio_get_container_fd vfio: generalize pci_vfio_get_group_no vfio: extract setup logic out of pci_vfio_map_resource vfio: move global vfio_cfg to eal_vfio.c vfio: make vfio_*_dma_map and iommu_types private vfio: rename and generalize eal_pci_vfio_mp_sync vfio: initialize vfio out of the PCI subsystem vfio: change VFIO init to be extendable lib/librte_eal/linuxapp/eal/Makefile | 5 +- lib/librte_eal/linuxapp/eal/eal.c | 33 ++ lib/librte_eal/linuxapp/eal/eal_pci.c | 17 +- lib/librte_eal/linuxapp/eal/eal_pci_init.h | 41 -- lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 517 +------------------- lib/librte_eal/linuxapp/eal/eal_vfio.c | 528 +++++++++++++++++++++ lib/librte_eal/linuxapp/eal/eal_vfio.h | 94 ++++ .../{eal_pci_vfio_mp_sync.c => eal_vfio_mp_sync.c} | 12 +- 8 files changed, 672 insertions(+), 575 deletions(-) create mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio.c rename lib/librte_eal/linuxapp/eal/{eal_pci_vfio_mp_sync.c => eal_vfio_mp_sync.c} (97%) -- 2.8.0