From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493AbbL2QVb (ORCPT ); Tue, 29 Dec 2015 11:21:31 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:51220 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752948AbbL2QV3 (ORCPT ); Tue, 29 Dec 2015 11:21:29 -0500 From: Arnd Bergmann To: Santosh Shukla Cc: alex.williamson@redhat.com, "H. Peter Anvin" , josh@joshtriplett.org, Greg Kroah-Hartman , akpm@linux-foundation.org, Linux Kernel Mailing List , linux-api@vger.kernel.org, yuanhan.liu@linux.intel.com, Santosh Shukla Subject: Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports Date: Tue, 29 Dec 2015 17:20:08 +0100 Message-ID: <1961979.Xhiud0jvNd@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <20140509191914.GA7286@jtriplet-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:jnOpU7+5cUMK7P0vSYFkhywI5o9tzYktmyos87PeUUsKv/JFBhd QrK6pcqYGd2Clohx0DMjaFkRXyPNCL2UJ5EahyauhxaAANS3pxvMSIzzcuOwSdwAXMPgj+7 15eiDvexBH1FcScy3+FdRtBjBvbb3fH/77XxwFDkMXrHchq7C2pDUAMKqWOEJICP+L8ShrB 8UAVBVWXnqdch44QpUaHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:k9PKw/3KP3A=:L716X0GLY653PBzd5e9mP5 RWQmbFIcRBxp4WzyNRXwow9Mm2oNQgoXrJPJC5GJyOI7Tn+SkwLm/uVvVzqh+c4dgW2TWEpYD oLByGx0yy9N+Jbi9PSBGqdHZ+n4VYT8LYQPQ3x7H4WhDHWxqGTBh6159r86rf60yF/mSeV6fB U6TjbKrvCqaQALZRoXpig7ZlJ65Y9BMS8BbHuhnoOQfnzVCnPGDLh6J0kd8jEqixBYL0qqbt5 fb+nE/vbrwbvFlxut4Lr9hljWqWMsaaq4D8qbrPor7RNQI2O/rt3F1VWn+mhjsCo51i4xMIQV 04ErVQaap0CPlzzzAf0s2iCl9c2Nlroa6W98IeH7Za8uXowr68RDFMaN0MzYsV2EMpJA208dH 8fl9tTfcYc02JOxUcEU44g5gIdwlggHnSw5X07WwiH1r9xChYtul2+Oe7VTYSUOCs/Z1it2Qx qlZ+JXEFHrbEEZLgwQh/iZ8swsBeFnMR1Xh6TQgfRAk8HFQVPJ2W4vshADIBFGnbeYfubghn+ eXYP1ENbbUVF2t05D9mcj2bxfXgzG8IK0DsYIOVOa0S41ittFvZdQARZXn6JWD0FTn8SDvuBB rDREGVsa9faHvaI8hal96HEfZxWxYgosjDgbL+aks35mCmPDMgF6eglc9TqWwkq7WGUa5Iiy3 cuXDgmmnDToJsV5FBJBXhIT8i0+Bqga0WPgO94gvd+M9pf2UN8iQ0IiFWpkFINOCLEa3krcBr 6yr2TvXoNFFzx0kf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 December 2015 21:25:15 Santosh Shukla wrote: > mistakenly added wrong email-id of alex, looping his correct one. > > On 29 December 2015 at 21:23, Santosh Shukla wrote: > > On 29 December 2015 at 18:58, Arnd Bergmann wrote: > >> On Wednesday 23 December 2015 17:04:40 Santosh Shukla wrote: > >>> On 23 December 2015 at 03:26, Arnd Bergmann wrote: > >>> > On Tuesday 22 December 2015, Santosh Shukla wrote: > >>> >> } > >>> >> > >>> >> So I care for /dev/ioport types interface who could do more than byte > >>> >> data copy to/from user-space. I tested this patch with little > >>> >> modification and could able to run pmd driver for arm/arm64 case. > >>> >> > >>> >> Like to know how to address pci_io region mapping problem for > >>> >> arm/arm64, in-case /dev/ioports approach is not acceptable or else I > >>> >> can spent time on restructuring the patch? > >>> >> > >>> > > >>> > For the use case you describe, can't you use the vfio framework to > >>> > access the PCI BARs? > >>> > > >>> > >>> I looked at file: drivers/vfio/pci/vfio_pci.c, func vfio_pci_map() and > >>> it look to me that it only maps ioresource_mem pci region, pasting > >>> code snap: > >>> > >>> if (!(pci_resource_flags(pdev, index) & IORESOURCE_MEM)) > >>> return -EINVAL; > >>> .... > >>> > >>> and I want to map ioresource_io pci region for arm platform in my > >>> use-case. Not sure vfio maps pci_iobar region? > >> > >> Mapping I/O BARs is not portable, notably it doesn't work on x86. > >> > >> You should be able access them using the read/write interface on > >> the vfio device. > >> > > Right, x86 doesn't care as iopl() could give userspace application > > direct access to ioports. > > > > Also, Alex in other dpdk thread [1] suggested someone to propose io > > bar mapping in vfio-pci, I guess in particular to non-x86 arch so I > > started working on it. > > > So what's wrong with just using the existing read/write API on all architectures? Arnd