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 124F2A04DB;
	Thu, 15 Oct 2020 19:45:55 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 1E5251DD3B;
	Thu, 15 Oct 2020 19:45:43 +0200 (CEST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com
 [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id EB8581DD32;
 Thu, 15 Oct 2020 19:45:40 +0200 (CEST)
Received: from pps.filterd (m0045847.ppops.net [127.0.0.1])
 by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id
 09FHjUmn018339; Thu, 15 Oct 2020 10:45:40 -0700
Received: from pps.reinject (localhost [127.0.0.1])
 by mx0b-0016f401.pphosted.com with ESMTP id 343cav0m10-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 15 Oct 2020 10:45:40 -0700
Received: from pps.reinject (m0045847.ppops.net [127.0.0.1])
 by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 09FHjSsH018320;
 Thu, 15 Oct 2020 10:45:39 -0700
Received: from sc-exch01.marvell.com ([199.233.58.181])
 by mx0a-0016f401.pphosted.com with ESMTP id 343aanufce-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
 Thu, 15 Oct 2020 04:39:08 -0700
Received: from DC5-EXCH02.marvell.com (10.69.176.39) by SC-EXCH01.marvell.com
 (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
 Thu, 15 Oct 2020 04:39:07 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by DC5-EXCH02.marvell.com
 (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
 Thu, 15 Oct 2020 04:39:06 -0700
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.176)
 by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id
 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 04:39:06 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=k5UmOlnrwA/7zD/tEeSjmOVUwZFcIkEw1qauYY+eieMJgEqppf2ZL3H6qj4xRctFDJbQD/RnTHJba8G2YGBhr3iCs+62r/hzmpvwzLR7wqAAIPSgpDUEP1x6tMf3xCgM4aWRFu/Pax8cQxaVkXRqIffrk3vxSrOrxDJv0w1HJFsWikQgoqlrEoNiOBR6UZ9SPtMHcznLjIxiAPfxDp2JoFp7NL5T3x60RVYtymr9P1X70lRbuNIdsSikd9ksiruN3XeGL9y1kTluKzS1ws6znqWRZ6SSyFxbjxygH9ym8/gf8Bl/ycotBrA5KF3PoGInpkfNfafkI3n2HvWl+d2ZLA==
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=iVtb5EaZ8/16rsbcpa0Wryp2AVmgEV+kbNOdwMGILsk=;
 b=kxUt2eS71/xGCniS4dkcoLN4sH0JHYLVelaPGnXQm1NFnI+dyF+z7Ol6XVVuXEJk1RvAsIwskBRsjgKrD6EyL3bgeCdfMkERrYX8T+sZO5SoGacV8zvI4SX27oknT/D58Q5ISgKEI6g3WTibDvmpTgHZtpKiUM843pQ9TIxBTizUmMYEgjiU6H+uvrAyMQxI63ZJJsWSKf3zFAqMS3iF+CTO0NIfKz7dt3mvPkgRU9XxbmwTT5eaSXtT4/o/IBbcRj6PufqPWh8QQybCgKWWAHjCurqkWZTUGdmPfVs9mcF4TSwWe+937srabILV9v7p6jQp2JN0inJOcSC7EONn2g==
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=selector1-marvell-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=iVtb5EaZ8/16rsbcpa0Wryp2AVmgEV+kbNOdwMGILsk=;
 b=IQlax5zID9eVNq3oRS1DPmRj+uq8Fo9bC2S6GK7Bo1rX0Ankwh1PE2+DGFhTOsls0L669SFQd50o7eD3YLFp/ACSaKJmDWWbvssCMJ51wrjqWfN4E2hbYFyHnunb4fNOQvJ14yhaUOztPUSTKvnW8dJaCDzk5Hn67LMv8PFxN3Q=
Authentication-Results: intel.com; dkim=none (message not signed)
 header.d=none;intel.com; dmarc=none action=none header.from=marvell.com;
Received: from BN8PR18MB2386.namprd18.prod.outlook.com (2603:10b6:408:68::25)
 by BN8PR18MB2434.namprd18.prod.outlook.com (2603:10b6:408:9c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Thu, 15 Oct
 2020 11:39:04 +0000
Received: from BN8PR18MB2386.namprd18.prod.outlook.com
 ([fe80::25af:7baf:528d:1dab]) by BN8PR18MB2386.namprd18.prod.outlook.com
 ([fe80::25af:7baf:528d:1dab%5]) with mapi id 15.20.3455.035; Thu, 15 Oct 2020
 11:39:04 +0000
Date: Thu, 15 Oct 2020 17:08:52 +0530
From: Nithin Dabilpuram <ndabilpuram@marvell.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
CC: <jerinj@marvell.com>, <dev@dpdk.org>, <stable@dpdk.org>
Message-ID: <20201015113852.GB15756@outlook.office365.com>
References: <20201012081106.10610-1-ndabilpuram@marvell.com>
 <20201012081106.10610-3-ndabilpuram@marvell.com>
 <05afb7f5-96bf-dffd-15dd-2024586f7290@intel.com>
 <20201015060914.GA32207@outlook.office365.com>
 <bd079e7f-d4f9-769f-2a45-1e93668c9c9b@intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bd079e7f-d4f9-769f-2a45-1e93668c9c9b@intel.com>
User-Agent: Mutt/1.12.2 (34cd43c) (2019-09-21)
X-Originating-IP: [1.6.215.26]
X-ClientProxiedBy: SG2PR03CA0098.apcprd03.prod.outlook.com
 (2603:1096:4:7c::26) To BN8PR18MB2386.namprd18.prod.outlook.com
 (2603:10b6:408:68::25)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from outlook.office365.com (1.6.215.26) by
 SG2PR03CA0098.apcprd03.prod.outlook.com (2603:1096:4:7c::26) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3499.8 via Frontend Transport; Thu, 15 Oct 2020 11:39:02 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2c73f6ef-780f-47c6-7f87-08d870feeb3a
X-MS-TrafficTypeDiagnostic: BN8PR18MB2434:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <BN8PR18MB24344487AE77376A8AA41164AF020@BN8PR18MB2434.namprd18.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:1360;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: KzOD83YYzHT75pU+g/ghTzAGnTqN6nts/OF9og9SPO8aAztv7hXhXl/EWPqV/dczGTBG+R6HefUU/gnZadFIyQgdZ8aRh/CpMJmnIZBvWVYq5hMzpUNjWC3MsEjrW0tDoMbMV8Fvcm29alsnBYZH47hE8/Wytlwaz5Tk0zv+ngq1dFwwABLUXyi4Nsud//VB2MgvTUe4iKQ17hNw5YQfCUrOGN42Dg2s8jW1OrGoaHScZYaTBA931THnOi3MO33RRplZFiFiCx6Bm7G7LPJQ7S6F12E1AbbnNEwfD5doTs/rW8BUaDifxWSniEN7CirlYMWFIBMO/ha1jz8pbmZZpbLkZEgtWIw1a2wMULHOV7ZxDL6rJH44AwThJ7E7dB0kJ1nZnaJtlduoKN43htb7Rvr5tN+e2oUlfy0QDnjx2snEJNKAMDnwY1khuN6YKYENi+rxVoxoKYwbDwiLRIN1H9Jd3OXKLRtPGX+ceOCCKPvNLUkenD0y9EgRxOE70o4f
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:BN8PR18MB2386.namprd18.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(4636009)(346002)(376002)(396003)(136003)(366004)(39860400002)(316002)(6916009)(86362001)(1076003)(66476007)(5660300002)(83380400001)(34490700002)(55016002)(66946007)(6506007)(52116002)(966005)(7696005)(33656002)(83080400001)(53546011)(66556008)(956004)(478600001)(4326008)(2906002)(1006002)(8676002)(16526019)(26005)(186003)(8936002)(9686003)(6666004)(36456003)(42976004);
 DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData: pH3sDA1zzpyNgX/FXF46t7ZCDdHRHsqF6fryX8rHJU9Fu8PSdOAdZEqYkPORE+VkK5I9PsQH8A5+B6AbQYFr3rbAGYQHdYRl5Z29PzjaYIVz6OuKipJmdEg1eQoxCRqv6Xackqgg4LME6Obq6U6QNNgzlPKIQTkslxUhJdarH5xFT/kGaHSwAo4x4h9GwNTPZniBY77ZqWXECFTgQBh6OJseKXMPapySO7amIp4WBW1vPTrv7U/f5spioCsVNxtd4WXcYAGFQ2rj3j9+79xn+jZjCIVmBer9PMU1F+cYHZ/w9M3qZrd4IEpwq83yv255v5sosvtLt/NX7KPntRApDeZpX0prqrwCjefTtP/AeP5IpYBJWgUikmwjLwE4mzzGtHLKaJWQXzE3SfxHW7gbt5xBc0baXmOEKvzPFnXLwKCEqwk2sixhY7u0HMFevV9XVPR+GWkgE8PaekoBehoCyYsZLXE/UdyqZTHNlSxntgNztWZlu/SOG2eW/5vPU6Y5KJKfeQgcjNe835cja0vvKlwmOh9uPsxoFAxGQMO4EMEH57gB3FzUIEwLMx9yxiGEW08dLryMmtiOXXdkXCXcthG3F0tf3JNbzTBZirwX1fYbvKGzXOIgR5dzCI7GOT3mJkXXnNZxJCH+dk3c+rrSOw==
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c73f6ef-780f-47c6-7f87-08d870feeb3a
X-MS-Exchange-CrossTenant-AuthSource: BN8PR18MB2386.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2020 11:39:04.4748 (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: W/OszNOEUFR8vsVSPUHRNRKNNpleNRe1ysEHeAq4mC8AwztGz5mt/98fDJ5tWwm44sPnjSRIn/tR7PjWye7fxQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR18MB2434
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,
 18.0.687 definitions=2020-10-15_07:2020-10-14, 2020-10-15 signatures=0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687
 definitions=2020-10-15_14:2020-10-14,
 2020-10-15 signatures=0
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 2/2] vfio: fix partial DMA
	unmapping for VFIO type1
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>


On Thu, Oct 15, 2020 at 11:00:59AM +0100, Burakov, Anatoly wrote:
> On 15-Oct-20 7:09 AM, Nithin Dabilpuram wrote:
> > On Wed, Oct 14, 2020 at 04:07:10PM +0100, Burakov, Anatoly wrote:
> > > External Email
> > > 
> > > ----------------------------------------------------------------------
> > > On 12-Oct-20 9:11 AM, Nithin Dabilpuram wrote:
> > > > Partial unmapping is not supported for VFIO IOMMU type1
> > > > by kernel. Though kernel gives return as zero, the unmapped size
> > > > returned will not be same as expected. So check for
> > > > returned unmap size and return error.
> > > > 
> > > > For case of DMA map/unmap triggered by heap allocations,
> > > > maintain granularity of memseg page size so that heap
> > > > expansion and contraction does not have this issue.
> > > 
> > > This is quite unfortunate, because there was a different bug that had to do
> > > with kernel having a very limited number of mappings available [1], as a
> > > result of which the page concatenation code was added.
> > > 
> > > It should therefore be documented that the dma_entry_limit parameter should
> > > be adjusted should the user run out of the DMA entries.
> > > 
> > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_lkml_155414977872.12780.13728555131525362206.stgit-40gimli.home_T_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=FZ_tPCbgFOh18zwRPO9H0yDx8VW38vuapifdDfc8SFQ&m=3GMg-634_cdUCY4WpQPwjzZ_S4ckuMHOnt2FxyyjXMk&s=TJLzppkaDS95VGyRHX2hzflQfb9XLK0OiOszSXoeXKk&e=
> 
> <snip>
> 
> > > >    			RTE_LOG(ERR, EAL, "  cannot clear DMA remapping, error %i (%s)\n",
> > > >    					errno, strerror(errno));
> > > >    			return -1;
> > > > +		} else if (dma_unmap.size != len) {
> > > > +			RTE_LOG(ERR, EAL, "  unexpected size %"PRIu64" of DMA "
> > > > +				"remapping cleared instead of %"PRIu64"\n",
> > > > +				(uint64_t)dma_unmap.size, len);
> > > > +			rte_errno = EIO;
> > > > +			return -1;
> > > >    		}
> > > >    	}
> > > > @@ -1853,6 +1869,12 @@ container_dma_unmap(struct vfio_config *vfio_cfg, uint64_t vaddr, uint64_t iova,
> > > >    		/* we're partially unmapping a previously mapped region, so we
> > > >    		 * need to split entry into two.
> > > >    		 */
> > > > +		if (!vfio_cfg->vfio_iommu_type->partial_unmap) {
> > > > +			RTE_LOG(DEBUG, EAL, "DMA partial unmap unsupported\n");
> > > > +			rte_errno = ENOTSUP;
> > > > +			ret = -1;
> > > > +			goto out;
> > > > +		}
> > > 
> > > How would we ever arrive here if we never do more than 1 page worth of
> > > memory anyway? I don't think this is needed.
> > 
> > container_dma_unmap() is called by user via rte_vfio_container_dma_unmap()
> > and when he maps we don't split it as we don't about his memory.
> > So if he maps multiple pages and tries to unmap partially, then we should fail.
> 
> Should we map it in page granularity then, instead of adding this
> discrepancy between EAL and user mapping? I.e. instead of adding a
> workaround, how about we just do the same thing for user mem mappings?

In heap mapping's we map and unmap it at huge page granularity as we will always
maintain that.

But here I think we don't know if user's allocation is huge page or collection of system
pages. Only thing we can do here is map it at system page granularity which
could waste entries if he say really is working with hugepages. Isn't ?

> 
> -- 
> Thanks,
> Anatoly