From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: xiao.w.wang@intel.com, qi.z.zhang@intel.com,
qingfu.cqf@alibaba-inc.com, thomas@monjalon.net,
dariusz.stojaczyk@intel.com, stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] vfio: allow secondary process to query IOMMU type
Date: Fri, 18 Jan 2019 10:13:26 +0000 [thread overview]
Message-ID: <41bd99e2-d02e-eb6c-8489-13fa07b555ea@intel.com> (raw)
In-Reply-To: <a306fe2084c9f99dc00d18309c730bdce1817e37.1547746215.git.anatoly.burakov@intel.com>
On 17-Jan-19 5:30 PM, Anatoly Burakov wrote:
> It is only possible to know IOMMU type of a given VFIO container
> by attempting to initialize it. Since secondary process never
> attempts to set up VFIO container itself (because they're shared
> between primary and secondary), it never knows which IOMMU type
> the container is using, and never sets up the appropriate config
> structures. This results in inability to perform DMA mappings in
> secondary process.
>
> Fix this by allowing secondary process to query IOMMU type of
> primary's default container at device initialization.
>
> Note that this fix is assuming we're only interested in default
> container.
>
> Bugzilla ID: 174
>
> Fixes: 6bcb7c95fe14 ("vfio: share default container in multi-process")
> Cc: dariusz.stojaczyk@intel.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
<...>
> + /* we now have an fd for default container, as well as its IOMMU type.
> + * now, set up default VFIO container config to match.
> + */
> + for (i = 0; i < RTE_DIM(iommu_types); i++) {
> + const struct vfio_iommu_type *t = &iommu_types[i];
> + if (t->type_id != iommu_type_id)
> + continue;
> +
> + /* we found our IOMMU type */
> + default_vfio_cfg->vfio_enabled = 1;
> + default_vfio_cfg->vfio_container_fd = vfio_container_fd;
> + default_vfio_cfg->vfio_iommu_type = t;
> + break;
> + }
Self-review: if IOMMU type wasn't found, we still return 0. Will fix in v2.
> +
> + return 0;
> +}
> +
> int
> rte_vfio_clear_group(int vfio_group_fd)
> {
> @@ -745,6 +805,26 @@ rte_vfio_setup_device(const char *sysfs_base, const char *dev_addr,
> else
> RTE_LOG(DEBUG, EAL, "Installed memory event callback for VFIO\n");
--
Thanks,
Anatoly
next prev parent reply other threads:[~2019-01-18 10:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 17:30 Anatoly Burakov
2019-01-18 10:13 ` Burakov, Anatoly [this message]
2019-01-18 10:24 ` [dpdk-dev] [PATCH v2] " Anatoly Burakov
2019-01-19 3:23 ` Wang, Xiao W
2019-01-21 10:13 ` Burakov, Anatoly
2019-01-21 10:21 ` Thomas Monjalon
2019-01-21 10:29 ` Burakov, Anatoly
2019-01-21 10:29 ` Stojaczyk, Dariusz
2019-01-21 15:19 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
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=41bd99e2-d02e-eb6c-8489-13fa07b555ea@intel.com \
--to=anatoly.burakov@intel.com \
--cc=dariusz.stojaczyk@intel.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
--cc=qingfu.cqf@alibaba-inc.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
--cc=xiao.w.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).