On Mon, Jun 20, 2022 at 06:10:37AM +0000, Dmitry Kozlyuk wrote: > > From: Bruce Richardson <bruce.richard...@intel.com> > > 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 <executable> > > > + > > > +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?
