From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9384CA0545 for ; Mon, 20 Jun 2022 10:37:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7ABA840150; Mon, 20 Jun 2022 10:37:42 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 2F90040150; Mon, 20 Jun 2022 10:37:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655714261; x=1687250261; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sHxFEiIZ2AIQlCv6zJfeaQUontfeCitKsg9ENK8LizM=; b=TF/dmDaYo9RPWnHCosShMlZIGbi7Vi0/7om2dKHPv+ruDlB6r3Qj4RcJ wILLc7TqMWyM2G+oUiLQc43YJ6E8Rf8NX1Oapt9M3m4TpGHMWXE6hPm6g +pVzxMfSleao+2O3AZg6csST+EdjUH8t7ChD1ZHzmoPsT/wAimL2Wlu/a y39OmAdaKlytQU4Fkv/73MlZF4sv5kTHVlLG00mGBhD1w+XyvPRmRRo1Y K/AylQZVahH+IK+nbvuiSL+Y+zX+9ZjHALyAm0g9aIVX/v6eBkGx1Vjb9 4sr1Ibe8qg8bxkDaJ3Qz62x/UYjNSS7fSvoqsI2LeTWpg0xvD1DnZ+rh1 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10380"; a="280895866" X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="280895866" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2022 01:37:40 -0700 X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="833012402" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.10.102]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 20 Jun 2022 01:37:38 -0700 Date: Mon, 20 Jun 2022 09:37:35 +0100 From: Bruce Richardson To: Dmitry Kozlyuk Cc: "dev@dpdk.org" , "stable@dpdk.org" , Anatoly Burakov Subject: Re: [PATCH v2 3/4] doc: give specific instructions for running as non-root Message-ID: References: <20220607234949.2311884-1-dkozlyuk@nvidia.com> <20220617112508.3823291-1-dkozlyuk@nvidia.com> <20220617112508.3823291-4-dkozlyuk@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Mon, Jun 20, 2022 at 06:10:37AM +0000, Dmitry Kozlyuk wrote: > > From: Bruce Richardson > > Sent: Friday, June 17, 2022 7:38 PM > > > [...] > > > +If the driver requires using physical addresses (PA), > > > +the executable file must be granted additional capabilities: > > > + > > > +* ``SYS_ADMIN`` to read ``/proc/self/pagemaps`` > > > +* ``IPC_LOCK`` to lock hugepages in memory > > > > Are either of these necessary if using vfio-pci and VA mode? I have > > seen it previously reported that IPC_LOCK is necessary for IOMMU > > memory mapping for DMA - at least for docker containers - so I'd > > like it confirmed that we don't need them in the in-memory case > > running on the host. If I get the chance I'll try double-checking > > by testing myself. > > Sorry, I don't have a physical device using vfio-pci to check. > MLX5 that I have tested doesn't need these capabilities, > but it locks memory from the kernel side. > Note that --in-memory doesn't imply --iova-mode=va. > > > > > > + > > > +.. code-block:: console > > > + > > > + setcap cap_ipc_lock,cap_sys_admin+ep > > > + > > > +If physical addresses are not accessible, > > > +the following message will appear during EAL initialization:: > > > + > > > + EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: > > Permission denied > > > + > > > +It is harmless in case PA are not needed. > > > + > > > > While this is probably worth having in the doc, I think we should > > really > > include a note here about using vfio-pci rather than uio and therefore > > not > > needing physical addresses. > > A note won't harm. There are also non-PCI devices, though. > > > > +For ``virtio`` PMD in legacy mode, ``SYS_RAWIO`` capability is > > required > > > +for ``iopl()`` call to enable access to PCI IO ports. > > > > > > > How "legacy" is legacy-mode? Is it still likely in widespread use that > > we need this? > > I don't really know. > The spec says that legacy support is optional > (2.2.3 Legacy Interface: A Note on Feature Bits) and it aims > to reduce the chance of a legacy driver attempting to drive the device > (4.1.2.1 Device Requirements: PCI Device Discovery). > OTOH, DPDK supports it and requirements must be documented. > I can add a line suggesting to use modern virtio, > but also don't mind removing this. > I suppose the main question for this legacy virtio bit is where it should be documented, more than if it should be. Given this is a GSG, we should try and avoid getting too deep into driver-specific issues, so I think we should omit legacy virtio here, but have it docuemented in the relevant virtio-specific doc. Does that seem reasonable?