[dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel module

Jerin Jacob jerinjacobk at gmail.com
Sun Oct 13 09:20:23 CEST 2019


On Thu, Oct 10, 2019 at 11:32 AM Jerin Jacob <jerinjacobk at gmail.com> wrote:
>
>
>
> On Thu, 10 Oct, 2019, 4:58 AM Stephen Hemminger, <stephen at networkplumber.org> wrote:
>>
>> On Tue, 8 Oct 2019 20:58:27 +0530
>> Jerin Jacob <jerinjacobk at gmail.com> wrote:
>>
>> > On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger, <stephen at networkplumber.org>
>> > wrote:
>> >
>> > > On Fri, 6 Sep 2019 14:42:30 +0530
>> > > <vattunuru at marvell.com> wrote:
>> > >
>> > > > From: Vamsi Attunuru <vattunuru at marvell.com>
>> > > >
>> > > > The DPDK use case such as VF representer or OVS offload etc
>> > > > would call for PF and VF PCIe devices to bind vfio-pci
>> > > > module to enable IOMMU protection.
>> > > >
>> > > > In addition to vSwitch use case, unlike, other PCI class of
>> > > > devices, Network class of PCIe devices would have additional
>> > > > responsibility on the PF devices such as promiscuous mode support
>> > > > etc.
>> > > >
>> > > > The above use cases demand VFIO needs bound to PF and its
>> > > > VF devices. This is use case is not supported in Linux kernel,
>> > > > due to a security issue where it is possible to have
>> > > > DoS in case if VF attached to guest over vfio-pci and netdev
>> > > > kernel driver runs on it and which something VF representer
>> > > > would like to enable it.
>> > > >
>> > > > Since we can not differentiate, the vfio-pci bounded VF devices
>> > > > runs DPDK application or netdev driver in guest, we can not
>> > > > introduce any scheme to fix DoS case and therefore not have
>> > > > proper support of this in the upstream kernel.
>> > > >
>> > > > The igb_uio enables such PF and VF binding support for
>> > > > non-iommu devices to make VF representer or OVS offload
>> > > > run on non-iommu devices with DoS vulnerability for netdev driver
>> > > > as VF.
>> > > >
>> > > > This kernel module, facilitate to enable SRIOV on PF devices,
>> > > > therefore, to run both PF and VF devices in VFIO mode knowing
>> > > > its impacts like igb_uio driver functions of non-iommu devices.
>> > > >
>> > > > Signed-off-by: Vamsi Attunuru <vattunuru at marvell.com>
>> > > > Signed-off-by: Jerin Jacob <jerinj at marvell.com>
>> > >
>> > > NAK
>> > > Having kernel drivers  not in upstream kernel is a long term
>> > > maintenance and security risk. Please work with upstream kernel
>> > > developers to get this merged there.
>> > >
>> >
>> > There is security issue in attaching DPDK PF driver and netdev bind to VF.
>> > So this scheme is not upsteamble to Linux kernel. Since rte_flow had VF
>> > action. We need this scheme to support VF action with VFIO. So, Out of tree
>> > is the only way as it is DPDK specific feature. Already sent patches to
>> > Linux kernel, it make sense to not accept this in upstream.  We are already
>> > exposing such features through igb-uio for non VFIO device. IMO, there
>> > should not be any disparity between igb-uio and VFIO in DPDK.
>> >
>> > If we are against out of tree module, let's remove igb-uio as well. We
>> > can't have different treatment for similar issues.
>>
>> You are right igb-uio is legacy and only exists for users unwilling to
>> change (such as old kernels which don't support vfio noiommu mode).
>
>
> It is NOT completely correct. This specific use case (allowing PF to bind DPDK and VF to have netdev in non VFIO mode allowed by igb-uio) now. So all non upsteamble features are going through igb-uio. That's is the main reason why igb-uio exist.
>
>
>
>> Eventually it should go as well. And the same for KNI.
>
>
>
> Nothing works without timeline. If that's the plan then decide the timeline.Please...
>
>
>>
>> Understand the pain, but this feels like a child who gets a no
>> answer from one parent and therefore thinks they can ask the other parent
>> and get a yes.
>>
>> Who is the person in the upstream kernel community that needs to understand
>> what is needed. Maybe another "I know what I am doing" kernel flag is needed
>> like no-iommu mode has.
>
>
> no-iommu case is different where we cannot screw Linux netdev driver, you can create a damage to your self that's an acceptable compromise.
>
> In this case, when DPDK PF bound application dies then it will impact netdev VF driver as gets stalled and there is a security issues to VF netdev driver that DPDK PF can intersect the netdev VF mailbox message.
>
> So this case is different where from Kernel PoV there is damange to netdev VF so this can not be accepted in Linux.
>
> One option is to add this piece of code igb-uio instead to adding new driver. What do you say?
>
> It is the problem for all non bifurcated drivers in DPDK not specific to Marvell.
>
> The workaround is to use igb-uio with non VFIO.
> We can not support UIO through performance reason hence we need a solution that works for VFIO due to HW accelerated mempool architecture (applicable for all NPU)
>
> We can not have VFIO vs UIO specific features disparity in DPDK. Please have same treatment. Either remove igb-uio hacks from Dpdk or enable non upsteamble features through igb-uio.So that there is no disparity for a specific use case / vendor.

Andrew Rybchenko already acked this patch and I provided enough data
on the need for this patch.
I hope there is no more confusion about the need for this patch.


More information about the dev mailing list