From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: "Xie, Huawei" <huawei.xie@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] vhost: fix mmap failure as len not aligned with hugepage size
Date: Thu, 12 Nov 2015 02:35:00 +0000 [thread overview]
Message-ID: <ED26CBA2FAD1BF48A8719AEF02201E3663E747@SHSMSX152.ccr.corp.intel.com> (raw)
In-Reply-To: <C37D651A908B024F974696C65296B57B4B183A1C@SHSMSX101.ccr.corp.intel.com>
> -----Original Message-----
> From: Xie, Huawei
> Sent: Wednesday, November 11, 2015 11:57 AM
> To: Tan, Jianfeng; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] vhost: fix mmap failure as len not aligned with
> hugepage size
>
> On 10/30/2015 2:52 PM, Jianfeng Tan wrote:
> > This patch fixes a bug under lower version linux kernel, mmap() fails
> > when
> Since which version Linux hugetlbfs changes the requirement of size alignment?
> > length is not aligned with hugepage size.
This link shows this bug was fixed in Linux kernel commit: dab2d3dc45ae7343216635d981d43637e1cb7d45
After my check, that patch was applied to long term version 3.4.110+
So distributions using 2.6.32 and 3.2.72 need this patch to make vhost work well.
https://bugzilla.kernel.org/show_bug.cgi?id=56881
> >
> > Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> > ---
> > lib/librte_vhost/vhost_user/virtio-net-user.c | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c
> > b/lib/librte_vhost/vhost_user/virtio-net-user.c
> > index a998ad8..641561c 100644
> > --- a/lib/librte_vhost/vhost_user/virtio-net-user.c
> > +++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
> > @@ -147,6 +147,10 @@ user_set_mem_table(struct vhost_device_ctx ctx,
> struct VhostUserMsg *pmsg)
> > /* This is ugly */
> > mapped_size = memory.regions[idx].memory_size +
> > memory.regions[idx].mmap_offset;
> > +
> > + alignment = get_blk_size(pmsg->fds[idx]);
> > + mapped_size = RTE_ALIGN_CEIL(mapped_size, alignment);
> Probably we could remove the alignment of mapped size in free_mem_region as
> well.
Yes, after aligning mapped_address when mmap(), this address does not need to be aligned again
when munmap(). But this will effect nothing, or incur any performance issue. I'm prone to take no
change to it.
> RTE_ALIGN_CEIL(
> region[idx].mapped_size, alignment) If we are not sure, leave it as it is.
> > +
> > mapped_address = (uint64_t)(uintptr_t)mmap(NULL,
> > mapped_size,
> > PROT_READ | PROT_WRITE, MAP_SHARED, @@ -154,9
> +158,11 @@
> > user_set_mem_table(struct vhost_device_ctx ctx, struct VhostUserMsg *pmsg)
> > 0);
> >
> > RTE_LOG(INFO, VHOST_CONFIG,
> > - "mapped region %d fd:%d to %p sz:0x%"PRIx64"
> off:0x%"PRIx64"\n",
> > + "mapped region %d fd:%d to:%p sz:0x%"PRIx64" "
> > + "off:0x%"PRIx64" align:0x%"PRIx64"\n",
> > idx, pmsg->fds[idx], (void *)(uintptr_t)mapped_address,
> > - mapped_size, memory.regions[idx].mmap_offset);
> > + mapped_size, memory.regions[idx].mmap_offset,
> > + alignment);
> >
> > if (mapped_address == (uint64_t)(uintptr_t)MAP_FAILED) {
> > RTE_LOG(ERR, VHOST_CONFIG,
> > @@ -166,7 +172,7 @@ user_set_mem_table(struct vhost_device_ctx ctx,
> > struct VhostUserMsg *pmsg)
> >
> > pregion_orig[idx].mapped_address = mapped_address;
> > pregion_orig[idx].mapped_size = mapped_size;
> > - pregion_orig[idx].blksz = get_blk_size(pmsg->fds[idx]);
> > + pregion_orig[idx].blksz = alignment;
> > pregion_orig[idx].fd = pmsg->fds[idx];
> >
> > mapped_address += memory.regions[idx].mmap_offset;
next prev parent reply other threads:[~2015-11-12 2:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 23:51 Jianfeng Tan
2015-11-06 1:23 ` Changchun Ouyang
2015-11-11 3:57 ` Xie, Huawei
2015-11-12 2:35 ` Tan, Jianfeng [this message]
2015-11-12 2:46 ` Xie, Huawei
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=ED26CBA2FAD1BF48A8719AEF02201E3663E747@SHSMSX152.ccr.corp.intel.com \
--to=jianfeng.tan@intel.com \
--cc=dev@dpdk.org \
--cc=huawei.xie@intel.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).