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.
next prev parent 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).