From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 20BC88E8C for ; Thu, 12 Nov 2015 03:46:17 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 11 Nov 2015 18:46:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,279,1444719600"; d="scan'208";a="849034681" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 11 Nov 2015 18:46:16 -0800 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 11 Nov 2015 18:46:16 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 11 Nov 2015 18:46:15 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.83]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.193]) with mapi id 14.03.0248.002; Thu, 12 Nov 2015 10:46:00 +0800 From: "Xie, Huawei" To: "Tan, Jianfeng" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] vhost: fix mmap failure as len not aligned with hugepage size Thread-Index: AdEcNQheLU49Pb3gTkGUNajMvN4Tbw== Date: Thu, 12 Nov 2015 02:46:00 +0000 Message-ID: References: <1446162713-130100-1-git-send-email-jianfeng.tan@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] vhost: fix mmap failure as len not aligned with hugepage size X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 02:46:18 -0000 On 11/12/2015 10:35 AM, Tan, Jianfeng wrote:=0A= >=0A= >> -----Original Message-----=0A= >> From: Xie, Huawei=0A= >> Sent: Wednesday, November 11, 2015 11:57 AM=0A= >> To: Tan, Jianfeng; dev@dpdk.org=0A= >> Subject: Re: [dpdk-dev] [PATCH] vhost: fix mmap failure as len not align= ed with=0A= >> hugepage size=0A= >>=0A= >> On 10/30/2015 2:52 PM, Jianfeng Tan wrote:=0A= >>> This patch fixes a bug under lower version linux kernel, mmap() fails= =0A= >>> when=0A= >> Since which version Linux hugetlbfs changes the requirement of size alig= nment?=0A= >>> length is not aligned with hugepage size.=0A= > This link shows this bug was fixed in Linux kernel commit: dab2d3dc45ae73= 43216635d981d43637e1cb7d45=0A= > After my check, that patch was applied to long term version 3.4.110+=0A= > So distributions using 2.6.32 and 3.2.72 need this patch to make vhost wo= rk well.=0A= > https://bugzilla.kernel.org/show_bug.cgi?id=3D56881=0A= OK, please add this in commit message, remove unnecessary RTE_ALIGN in=0A= free_memory_region, and add comment to the code because our fix is a=0A= workaround to kernel hugetlbfs implementation issue.=0A= >=0A= >>> Signed-off-by: Jianfeng Tan =0A= >>> ---=0A= >>> lib/librte_vhost/vhost_user/virtio-net-user.c | 12 +++++++++---=0A= >>> 1 file changed, 9 insertions(+), 3 deletions(-)=0A= >>>=0A= >>> diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c=0A= >>> b/lib/librte_vhost/vhost_user/virtio-net-user.c=0A= >>> index a998ad8..641561c 100644=0A= >>> --- a/lib/librte_vhost/vhost_user/virtio-net-user.c=0A= >>> +++ b/lib/librte_vhost/vhost_user/virtio-net-user.c=0A= >>> @@ -147,6 +147,10 @@ user_set_mem_table(struct vhost_device_ctx ctx,=0A= >> struct VhostUserMsg *pmsg)=0A= >>> /* This is ugly */=0A= >>> mapped_size =3D memory.regions[idx].memory_size +=0A= >>> memory.regions[idx].mmap_offset;=0A= >>> +=0A= >>> + alignment =3D get_blk_size(pmsg->fds[idx]);=0A= >>> + mapped_size =3D RTE_ALIGN_CEIL(mapped_size, alignment);=0A= >> Probably we could remove the alignment of mapped size in free_mem_region= as=0A= >> well.=0A= > Yes, after aligning mapped_address when mmap(), this address does not nee= d to be aligned again=0A= > when munmap(). But this will effect nothing, or incur any performance iss= ue. I'm prone to take no=0A= > change to it.=0A= >=0A= >> RTE_ALIGN_CEIL(=0A= >> region[idx].mapped_size, alignment) If we are not sure, leave it= as it is.=0A= >>> +=0A= >>> mapped_address =3D (uint64_t)(uintptr_t)mmap(NULL,=0A= >>> mapped_size,=0A= >>> PROT_READ | PROT_WRITE, MAP_SHARED, @@ -154,9=0A= >> +158,11 @@=0A= >>> user_set_mem_table(struct vhost_device_ctx ctx, struct VhostUserMsg *pm= sg)=0A= >>> 0);=0A= >>>=0A= >>> RTE_LOG(INFO, VHOST_CONFIG,=0A= >>> - "mapped region %d fd:%d to %p sz:0x%"PRIx64"=0A= >> off:0x%"PRIx64"\n",=0A= >>> + "mapped region %d fd:%d to:%p sz:0x%"PRIx64" "=0A= >>> + "off:0x%"PRIx64" align:0x%"PRIx64"\n",=0A= >>> idx, pmsg->fds[idx], (void *)(uintptr_t)mapped_address,=0A= >>> - mapped_size, memory.regions[idx].mmap_offset);=0A= >>> + mapped_size, memory.regions[idx].mmap_offset,=0A= >>> + alignment);=0A= >>>=0A= >>> if (mapped_address =3D=3D (uint64_t)(uintptr_t)MAP_FAILED) {=0A= >>> RTE_LOG(ERR, VHOST_CONFIG,=0A= >>> @@ -166,7 +172,7 @@ user_set_mem_table(struct vhost_device_ctx ctx,=0A= >>> struct VhostUserMsg *pmsg)=0A= >>>=0A= >>> pregion_orig[idx].mapped_address =3D mapped_address;=0A= >>> pregion_orig[idx].mapped_size =3D mapped_size;=0A= >>> - pregion_orig[idx].blksz =3D get_blk_size(pmsg->fds[idx]);=0A= >>> + pregion_orig[idx].blksz =3D alignment;=0A= >>> pregion_orig[idx].fd =3D pmsg->fds[idx];=0A= >>>=0A= >>> mapped_address +=3D memory.regions[idx].mmap_offset;=0A= >=0A= =0A=