From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 96BB7A0547
for <public@inbox.dpdk.org>; Fri, 5 Mar 2021 14:54:45 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 7D20322A390;
Fri, 5 Mar 2021 14:54:45 +0100 (CET)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
by mails.dpdk.org (Postfix) with ESMTP id 9AD8422A35B;
Fri, 5 Mar 2021 14:54:41 +0100 (CET)
IronPort-SDR: Qqro0DKm7DgnmcoA4VFg6JX43idahI5TMnny1+OEnG6Anlm4kSmEzWu354Z7hVUXQPp0xJC8i7
Kvdhpz4JQROw==
X-IronPort-AV: E=McAfee;i="6000,8403,9913"; a="184275620"
X-IronPort-AV: E=Sophos;i="5.81,224,1610438400"; d="scan'208";a="184275620"
Received: from orsmga008.jf.intel.com ([10.7.209.65])
by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
05 Mar 2021 05:54:40 -0800
IronPort-SDR: TINAu+7w/3bFecfdy+r3rQ81gSPNFVxasfFtdEINz+vSMoWMH+Ox3j67BhfJh5LPo6nSWVyZrd
RqFjU7CtuXcw==
X-IronPort-AV: E=Sophos;i="5.81,224,1610438400"; d="scan'208";a="408306024"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.194.96])
([10.213.194.96])
by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
05 Mar 2021 05:54:38 -0800
To: David Marchand <david.marchand@redhat.com>,
Nithin Dabilpuram <ndabilpuram@marvell.com>
Cc: David Christensen <drc@linux.vnet.ibm.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>, dev <dev@dpdk.org>,
dpdk stable <stable@dpdk.org>
References: <20201012081106.10610-1-ndabilpuram@marvell.com>
<20210115073243.7025-1-ndabilpuram@marvell.com>
<20210115073243.7025-2-ndabilpuram@marvell.com>
<CAJFAV8zq13bSLUMKAg7FmD9i2qHBJNrMsnpPZff-d-Q6s67cBw@mail.gmail.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <d8bf297d-6347-f065-d507-4468a30d35ca@intel.com>
Date: Fri, 5 Mar 2021 13:54:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <CAJFAV8zq13bSLUMKAg7FmD9i2qHBJNrMsnpPZff-d-Q6s67cBw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-stable] [PATCH v8 1/3] vfio: revert changes for map
contiguous areas in one go
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On 05-Mar-21 7:50 AM, David Marchand wrote:
> On Fri, Jan 15, 2021 at 8:33 AM Nithin Dabilpuram
> <ndabilpuram@marvell.com> wrote:
>>
>> In order to save DMA entries limited by kernel both for externel
>> memory and hugepage memory, an attempt was made to map physically
>> contiguous memory in one go. This cannot be done as VFIO IOMMU type1
>> does not support partially unmapping a previously mapped memory
>> region while Heap can request for multi page mapping and
>> partial unmapping.
>> Hence for going back to old method of mapping/unmapping at
>> memseg granularity, this commit reverts
>> commit d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
>>
>> Also add documentation on what module parameter needs to be used
>> to increase the per-container dma map limit for VFIO.
>>
>> Fixes: d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
>> Cc: anatoly.burakov@intel.com
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
>> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> Acked-by: David Christensen <drc@linux.vnet.ibm.com>
>
> There is a regression reported in bz: https://bugs.dpdk.org/show_bug.cgi?id=649
>
> I assigned it to Anatoly for now.
> Nithin, can you have a loo too?
>
> Thanks.
>
>
I've responded on the bug tracker as well, but to repeat it here: this
is not a regression, this is intended behavior. We cannot do anything
about this.
--
Thanks,
Anatoly