DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: vattunuru@marvell.com
Cc: dev@dpdk.org, jerinj@marvell.com
Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel module
Date: Fri, 06 Sep 2019 11:45:03 +0200	[thread overview]
Message-ID: <1612178.XsdEgM4R2a@xps> (raw)
In-Reply-To: <20190906091230.13923-1-vattunuru@marvell.com>

06/09/2019 11:12, vattunuru@marvell.com:
> From: Vamsi Attunuru <vattunuru@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@marvell.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>

Sorry I fail to properly understand the explanation above.
Please try to split in shorter sentences.

About the request to add an out-of-tree Linux kernel driver,
I guess Jerin is well aware that we don't want such anymore.



  reply	other threads:[~2019-09-06  9:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06  9:12 vattunuru
2019-09-06  9:45 ` Thomas Monjalon [this message]
2019-09-06 13:27   ` Jerin Jacob Kollanukkaran
2019-09-25  4:06     ` Vamsi Krishna Attunuru
2019-09-25  7:18       ` Andrew Rybchenko
2019-10-08  5:07     ` Vamsi Krishna Attunuru
2019-10-31 17:03     ` Thomas Monjalon
2019-11-01 11:54       ` Luca Boccassi
2019-11-01 12:12         ` Jerin Jacob
2019-11-04 11:16         ` Bruce Richardson
2019-11-05 10:09           ` Luca Boccassi
2019-11-06 22:32       ` Alex Williamson
2019-11-07  5:02         ` Jerin Jacob
2019-11-15  6:57           ` Thomas Monjalon
2019-11-15  7:01             ` Jerin Jacob
2019-10-08 15:12 ` Stephen Hemminger
2019-10-08 15:28   ` Jerin Jacob
2019-10-09 23:28     ` Stephen Hemminger
2019-10-10  6:02       ` Jerin Jacob
2019-10-13  7:20         ` Jerin Jacob
2019-10-16 11:37           ` Jerin Jacob
2019-10-23 17:08             ` Jerin Jacob
2019-10-24 11:08       ` Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1612178.XsdEgM4R2a@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=vattunuru@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).