From: Tiwei Bie <tiwei.bie@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: maxime.coquelin@redhat.com, zhihong.wang@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] net/virtio-user: avoid parsing process mappings
Date: Tue, 28 Aug 2018 16:42:03 +0800 [thread overview]
Message-ID: <20180828084203.GA69008@fbsd.sh.intel.com> (raw)
In-Reply-To: <986b3012-552b-6673-d716-9acacb5e9528@intel.com>
On Tue, Aug 28, 2018 at 09:12:38AM +0100, Burakov, Anatoly wrote:
> On 28-Aug-18 8:53 AM, Tiwei Bie wrote:
[...]
> >
> > - for (i = 0; i < num; ++i) {
> > - mr = &msg->payload.memory.regions[i];
> > - mr->guest_phys_addr = huges[i].addr; /* use vaddr! */
> > - mr->userspace_addr = huges[i].addr;
> > - mr->memory_size = huges[i].size;
> > - mr->mmap_offset = 0;
> > - fds[i] = open(huges[i].path, O_RDWR);
> > + start_addr = (uint64_t)(uintptr_t)ms->addr;
> > + end_addr = start_addr + ms->len;
> > +
> > + /*
> > + * XXX workaround!
> > + *
> > + * For --single-file-segments case, offset should be:
> > + * offset = rte_fbarray_find_idx(&msl->memseg_arr, ms) * msl->page_sz;
> > + *
> > + * But it's not true for non-single-file-segments case.
> > + *
> > + * This is a temporary workaround which assumes the file will
> > + * also be mapped from the beginning in --single-file-segments
> > + * case. It should be replaced when we have a memory API to
> > + * get the offset.
>
> Yes, this is an unfortunate consequence of having split personalities in
> memory subsystem. A good solution would be to just deprecate
> non-single-file segments mode and always use it, but we cannot do that
> because we support kernel versions that do not support fallocate() on
> hugetlbfs (and it still leaves legacy mem mode, which effectively
> behaves like non-single-file segments as far as virtio is concerned).
>
> How about we add this API in v2 for seg fd patchset?
Sure, thanks!
Besides, I saw another minor issue. When --legacy-mem
and --single-file-segments are both specified, the EAL
init doesn't fail, but fd can't be got successfully.
>
> > + */
> > + offset = 0;
> > +
[...]
> > @@ -109,9 +111,24 @@ is_vhost_user_by_type(const char *path)
> > int
> > virtio_user_start_device(struct virtio_user_dev *dev)
> > {
> > + struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
> > uint64_t features;
> > int ret;
> >
> > + /*
> > + * XXX workaround!
> > + *
> > + * We need to make sure that the locks will be
> > + * taken in the correct order to avoid deadlocks.
> > + *
> > + * Before releasing this lock, this thread should
> > + * not trigger any memory hotplug events.
> > + *
> > + * This is a temporary workaround, and should be
> > + * replaced when we get proper supports from the
> > + * memory subsystem in the future.
> > + */
> > + rte_rwlock_read_lock(&mcfg->memory_hotplug_lock);
>
> This feels like it should be a separate patch, because it fixes the
> issue that exists independently of whether we have segment fd API or not.
Yeah, I'll put it in a separate patch.
>
> > pthread_mutex_lock(&dev->mutex);
> >
> > if (is_vhost_user_by_type(dev->path) && dev->vhostfd < 0)
> > @@ -152,10 +169,12 @@ virtio_user_start_device(struct virtio_user_dev *dev)
> >
> > dev->started = true;
> > pthread_mutex_unlock(&dev->mutex);
> > + rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
> >
> > return 0;
> > error:
> > pthread_mutex_unlock(&dev->mutex);
> > + rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
> > /* TODO: free resource here or caller to check */
> > return -1;
> > }
> >
>
>
> --
> Thanks,
> Anatoly
next prev parent reply other threads:[~2018-08-28 8:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 7:53 Tiwei Bie
2018-08-28 8:12 ` Burakov, Anatoly
2018-08-28 8:42 ` Tiwei Bie [this message]
2018-08-28 12:56 ` Burakov, Anatoly
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=20180828084203.GA69008@fbsd.sh.intel.com \
--to=tiwei.bie@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=zhihong.wang@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).