From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id DA114A2EDB
	for <public@inbox.dpdk.org>; Fri,  6 Sep 2019 15:27:57 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id B73FC1F40E;
	Fri,  6 Sep 2019 15:27:57 +0200 (CEST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com
 [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 1C88D1F40E
 for <dev@dpdk.org>; Fri,  6 Sep 2019 15:27:56 +0200 (CEST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1])
 by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id
 x86DPo32014296; Fri, 6 Sep 2019 06:27:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=pfpt0818;
 bh=KoBvNFW5GB9awxFm5dKgq1iR3eSfTjt0gXhXNvckIt0=;
 b=sMH3t+9bPSFPo1wfakqe4RZdxPzXvy2u8d1CNsbF6ATULVEk0OEH8KJ5V5isCAG+NlE9
 zWt49+s38d9V2T+P6xATQslZhjzo7awAnKZmGAbfuL8dPhVThs1YbcmJnq2oetZbNeYT
 3/JnAwr10ROBg16vNnEpHS+mwNQdzcF9v1jPygrAu1wWjgCAMNilHsfueG5/mw7BNltu
 KtgY1A1RNAaBDsPM42rt/kaycC5liVikYBOXPSK+PdFUhHDK22ScRce9m2v6WkX58IgT
 pxtaGNEt64zargwJmPuyrDQeGRS2exD/R666LB1gv0w9kc7paiKeQ3YbXsHHY8samv9D Tw== 
Received: from sc-exch03.marvell.com ([199.233.58.183])
 by mx0b-0016f401.pphosted.com with ESMTP id 2uqrdmqmgf-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
 Fri, 06 Sep 2019 06:27:55 -0700
Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com
 (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Sep
 2019 06:27:52 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.54) by
 SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server
 (TLS) id
 15.0.1367.3 via Frontend Transport; Fri, 6 Sep 2019 06:27:52 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=U8IGngjeL9hxzMe8Cb2wxE0r1+H92ZgXyI91LnhVupuJoxhpy2XHpvhas/oiB1qI8kQisHQDMePJnENphUDPtuXH1UhKmyHpTPRsUh+0gTGg9RPg4uXbOMLWjE65fYd9oX922sea7DtjL/4aKsJyLvVYMvB12t828YffVijicGip37YYiBqmAnlYA3pQ6zYTKQID8Mymli36YVJm2WTxuIVrFY/Fa6NSM/pAdSDAcK1a8OogZMqf6O+3xUBMsqQLACrVXeYbseqBaF5vpgLsXFxncR152xDcUfq27ODIeYjndMjhZFUPehblxF40sXklylsjMN2WTYEkxcQCBJuvfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=KoBvNFW5GB9awxFm5dKgq1iR3eSfTjt0gXhXNvckIt0=;
 b=BXA5ne+TFuo8qWzh73XN/XmhwAxjyjcKIxqie3lA2Pwd5SGOTu/j4WFU1tQaVmyVVe2+viFhto4/tNPuXs4zCVWfZf2MFPfcpEAPmvcfMlFB21PVzBkByp1ex3Vpg0pVwCrr7kXqqDUNLT0/eMCQ5ON9yY0HRTfsvG8lIe+nPm6JmymPk3fmmUvHPO8/lY/mNK0iIlkfzE9ywGiuoqp8yjuVxKH/joTRn8dbJuvCxsSlBfCoXeChLT7IXyKfkg48cmSDn4nZx744zvma3sXzE5xRlWEXiEx+m3gGbO4sdTIWw0Vd1MYLRH7apRTnKeroZPH1vttkSHZTCIx+qkVgbA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com;
 dkim=pass header.d=marvell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=KoBvNFW5GB9awxFm5dKgq1iR3eSfTjt0gXhXNvckIt0=;
 b=AQJAXg8x/gGhQG0o70keE+gG3c1dry8jO7FdaFJM8NskzfXgysVlLjd/Q1PFUQMNAL5q7hiPFjDq3yUSYTfI9ndplJvzAHZNkJU/lOnqjpGF2HSx62K9qTFaA8XzSMXG0nrmofjL8ksq/hV/YVu6NiUKngcYB0hz87uB5LOSaPU=
Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by
 BYAPR18MB3031.namprd18.prod.outlook.com (20.179.94.209) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2220.18; Fri, 6 Sep 2019 13:27:50 +0000
Received: from BYAPR18MB2424.namprd18.prod.outlook.com
 ([fe80::1d8b:430f:c74a:33]) by BYAPR18MB2424.namprd18.prod.outlook.com
 ([fe80::1d8b:430f:c74a:33%6]) with mapi id 15.20.2241.018; Fri, 6 Sep 2019
 13:27:50 +0000
From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: Thomas Monjalon <thomas@monjalon.net>, Vamsi Krishna Attunuru
 <vattunuru@marvell.com>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel
 module
Thread-Index: AQHVZJNK5enIcsnWqUCbwjf3VIAu4aceZlyAgAAxNNA=
Date: Fri, 6 Sep 2019 13:27:50 +0000
Message-ID: <BYAPR18MB2424ACA16BBA9D6387FBA10CC8BA0@BYAPR18MB2424.namprd18.prod.outlook.com>
References: <20190906091230.13923-1-vattunuru@marvell.com>
 <1612178.XsdEgM4R2a@xps>
In-Reply-To: <1612178.XsdEgM4R2a@xps>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [116.68.105.78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8530c65e-7b28-4326-b1a3-08d732ce03c0
x-microsoft-antispam: BCL:0; PCL:0;
 RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020);
 SRVR:BYAPR18MB3031; 
x-ms-traffictypediagnostic: BYAPR18MB3031:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR18MB303115E43C1CE331132C4022C8BA0@BYAPR18MB3031.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(189003)(199004)(13464003)(446003)(55236004)(486006)(476003)(53546011)(6506007)(11346002)(256004)(102836004)(26005)(81156014)(110136005)(33656002)(55016002)(316002)(229853002)(53936002)(14444005)(6636002)(9686003)(186003)(8936002)(6306002)(4326008)(71200400001)(71190400001)(6246003)(5024004)(25786009)(86362001)(3846002)(7696005)(6116002)(2906002)(99286004)(76116006)(14454004)(66446008)(64756008)(6436002)(66946007)(52536014)(66476007)(478600001)(8676002)(5660300002)(76176011)(74316002)(966005)(66556008)(81166006)(66066001)(305945005)(7736002);
 DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB3031;
 H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;
 PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: marvell.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3yTFV56ahzdGq8WVGpzUjNMJtfrfEV0s5+aVcDcY7596TGgYks7Xd61CPyr9WFGha/ufZiklS3UzfOG+cK0drlua8cfL7ysC7CArvb346+L8YMMyUnw3ac6l+TybfIxwyVG1Jfe+mRbLfLhx7OwURA1Oc82j+z3tyT1hgbA2XHw9NsTu5qOMdkRQoxoG6ZExXD4gALOX5PbV7xuGJnkCBLbKBZFAutJH9/46vCPchjAi/sMvAK4BERPG4jhIyGlnj1T8tvHSW5c+2h3Keeh9ka/KjzunYtW6i/X0rilFQRS8+A1XRfDY/5J+8PIdpITQeHDQruuNVlUA9as7iBM8BC9O3SLoWsoQHMfKHZwND/UhlLkQi7TmDujLHqEI2PRZQe9Z9dT4xc9ta1/kbDuwNyZ7EQzOLtYv68ElZoKKq8w=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8530c65e-7b28-4326-b1a3-08d732ce03c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 13:27:50.2427 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nhb2sDcDYyoY9+LJofJhk9TrU0rIobxs81+kjBOYW11cPybSHnmGYC/FB02ROVtu3qYPhVAq+UCDRDFUEWkoCQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB3031
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8
 definitions=2019-09-06_06:2019-09-04,2019-09-06 signatures=0
Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf
 kernel module
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, September 6, 2019 3:15 PM
> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf ke=
rnel
> module
>=20
> 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>
>=20
> Sorry I fail to properly understand the explanation above.
> Please try to split in shorter sentences.
>=20
> About the request to add an out-of-tree Linux kernel driver, I guess Jeri=
n is well
> aware that we don't want such anymore.

Yes. I am aware of it. I don't like the out of tree modules either. But, Th=
is case,
I suggested Vamsi to have out of tree module.

Let me describe the issue and let us discuss how to tackle the  problem:

# Linux kernel wont allow VFIO PF to have SRIOV enable.

Patches and on going discussion are here:
https://patchwork.kernel.org/patch/10522381/
https://lwn.net/Articles/748526/

Based on my understanding the reason for NOT allowing the
VFIO PF to have SRIOV enable is genuine from kernel point of
View but not from DPDK point of view.

Here is the sequence  to describe the problem
1) Consider Linux kernel allowed VFIO PCI SRIOV enable
2) PF bound to vfio-pci
3) using SRIOV infrastructure of vfio-pci  PF driver,
VFs  are created
4) DPDK application bound to PF and VF, No issue here.
5) Assume DPDK application bound to PF and VF bound
To netdev kernel driver. Now, there is a genuine  concern
>From kernel point of view that, DPDK PF can intercept,
VF mailbox message or so and deny the Kernel request
Or what if DPDK PF application crashes?

To avoid the case (5), (3) is not allowed in stock kernel.
Which makes sense IMO.

Now, From DPDK PoV, step 5 is valid as we have
Rte_flow's VF action etc used to enable such case.
Where, user can program the PF's rte_flow to steer
Some traffic to VF, where VF can be, DPDK application or
Linux kernel netdev driver.

This patch enables the step (3) to enable step (5) from DPDK
PoV. i.e DPDK needs to allow PF to bind to DPDK with VFs.

Why this issue now:
- igb_uio kernel driver is used as enabling step (3)
See store_max_vfs() kernel/linux/igb_uio/igb_uio.c
 This is fine for non-iommu device, IOMMU devices
needs VFIO.
- We would like support VFIO for IOMMU protection
And enable step (5) as DPDK supports form the spec level.
i.e need to fix feature disparity between iommu vs
non-iommu based devices.

Note:
We may not need a  brand new kernel module, we could move
this logic to igb_uio if maintenance is concern.







=20


=20

=20




-=20
=20






>=20