All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Lucero <alejandro.lucero@netronome.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"JPF@zurich.ibm.com" <JPF@zurich.ibm.com>,
	Gowrishankar Muthukrishnan <gowrishankar.m@in.ibm.com>
Subject: Re: [PATCH dpdk 4/5] vfio: Do try setting IOMMU type if already set
Date: Wed, 26 Apr 2017 09:45:05 +0100	[thread overview]
Message-ID: <CAD+H993pX8uM1sF09edRAuSJpxESnNCXA4+hGTNoJqEuZJvqHg@mail.gmail.com> (raw)
In-Reply-To: <C6ECDF3AB251BE4894318F4E4512369782210A33@IRSMSX109.ger.corp.intel.com>

On Wed, Apr 26, 2017 at 9:27 AM, Burakov, Anatoly <anatoly.burakov@intel.com
> wrote:

> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alexey
> > Kardashevskiy
> > Sent: Wednesday, April 26, 2017 8:51 AM
> > To: Andrew Rybchenko <arybchenko@solarflare.com>; dev@dpdk.org
> > Cc: JPF@zurich.ibm.com; Gowrishankar Muthukrishnan
> > <gowrishankar.m@in.ibm.com>
> > Subject: Re: [dpdk-dev] [PATCH dpdk 4/5] vfio: Do try setting IOMMU type
> if
> > already set
> >
> > On 21/04/17 18:54, Andrew Rybchenko wrote:
> > > On 04/20/2017 10:24 AM, Alexey Kardashevskiy wrote:
> > >> The existing code correctly checks if a container is set to a group
> > >> and does not try attaching a group to a container for a
> second/third/...
> > >> device from the same IOMMU group.
> > >>
> > >> However it still tries to set IOMMU type to a container for every
> > >> device in a group which produces failure and closes container and
> group
> > fds.
> > >>
> > >> This moves vfio_set_iommu_type() and DMA mapping code under:
> > >> if (!(group_status.flags & VFIO_GROUP_FLAGS_CONTAINER_SET))
> > >>
> > >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > >> ---
> > >>   lib/librte_eal/linuxapp/eal/eal_vfio.c | 50
> > >> +++++++++++++++++-----------------
> > >>   1 file changed, 25 insertions(+), 25 deletions(-)
> > >>
> > >> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
> > >> b/lib/librte_eal/linuxapp/eal/eal_vfio.c
> > >> index 6e2e84ca7..46f951f4d 100644
> > >> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
> > >> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
> > >> @@ -298,33 +298,33 @@ vfio_setup_device(const char *sysfs_base,
> > const
> > >> char *dev_addr,
> > >>               clear_group(vfio_group_fd);
> > >>               return -1;
> > >>           }
> > >> -    }
> > >>   -    /*
> > >> -     * pick an IOMMU type and set up DMA mappings for container
> > >> -     *
> > >> -     * needs to be done only once, only when first group is assigned
> to
> > >> -     * a container and only in primary process. Note this can happen
> > >> several
> > >> -     * times with the hotplug functionality.
> > >> -     */
> > >> -    if (internal_config.process_type == RTE_PROC_PRIMARY &&
> > >> -            vfio_cfg.vfio_active_groups == 1) {
> > >> -        /* select an IOMMU type which we will be using */
> > >> -        const struct vfio_iommu_type *t =
> > >> +        /*
> > >> +         * pick an IOMMU type and set up DMA mappings for container
> > >> +         *
> > >> +         * needs to be done only once, only when first group is
> assigned to
> > >> +         * a container and only in primary process. Note this can
> > >> + happen
> > >> several
> > >> +         * times with the hotplug functionality.
> > >> +         */
> > >> +        if (internal_config.process_type == RTE_PROC_PRIMARY &&
> > >> +                vfio_cfg.vfio_active_groups == 1) {
> > >> +            /* select an IOMMU type which we will be using */
> > >> +            const struct vfio_iommu_type *t =
> > >>                   vfio_set_iommu_type(vfio_cfg.vfio_container_fd);
> > >> -        if (!t) {
> > >> -            RTE_LOG(ERR, EAL, "  %s failed to select IOMMU type\n",
> > >> dev_addr);
> > >> -            close(vfio_group_fd);
> > >> -            clear_group(vfio_group_fd);
> > >> -            return -1;
> > >> -        }
> > >> -        ret = t->dma_map_func(vfio_cfg.vfio_container_fd);
> > >> -        if (ret) {
> > >> -            RTE_LOG(ERR, EAL, "  %s DMA remapping failed, "
> > >> -                    "error %i (%s)\n", dev_addr, errno,
> strerror(errno));
> > >> -            close(vfio_group_fd);
> > >> -            clear_group(vfio_group_fd);
> > >> -            return -1;
> > >> +            if (!t) {
> > >> +                RTE_LOG(ERR, EAL, "  %s failed to select IOMMU
> > >> + type\n",
> > >> dev_addr);
> > >> +                close(vfio_group_fd);
> > >> +                clear_group(vfio_group_fd);
> > >> +                return -1;
> > >> +            }
> > >> +            ret = t->dma_map_func(vfio_cfg.vfio_container_fd);
> > >> +            if (ret) {
> > >> +                RTE_LOG(ERR, EAL, "  %s DMA remapping failed, "
> > >> +                        "error %i (%s)\n", dev_addr, errno,
> > >> strerror(errno));
> > >> +                close(vfio_group_fd);
> > >> +                clear_group(vfio_group_fd);
> > >> +                return -1;
> > >> +            }
> > >>           }
> > >>       }
> > >
> > > It looks like a duplicate of the earlier submitted patch
> > > http://dpdk.org/ml/archives/dev/2017-April/063077.html
> >
> >
> > It is a duplicate indeed, what needs to be done to have it accepted in
> the
> > mainline tree?
>
> I think Alejandro Lucero (CC'd) mentioned that he has another patch for
> similar issue that he's working on (for ports being
> assigned to the same IOMMU group). That patch would presumably fix this
> issue as well, so I'm inclined to
> wait for that one. If that's not happening, then we can accept either this
> one or the earlier ones, and fix the
> remaining issues (I have a setup where I can attempt to reproduce the
> issue, so that should be quick enough).
>
>
I was counting on first submitted patch being accepted.

There is another thing to solve which is to unplug ports when there are
more than one (already plugged) in an IOMMU group. I have a patch for this
but I can not test it for that scenario, just for the "normal" one with one
port/device per IOMMU group. I'm working on having a way for testing the
first case.

Once I have said that, I would like to comment code after the patch fixing
the plug issue is fine. What I mean is, unplugging a device when more than
one device already plugged from the same IOMMU group do not break things.
Of course, I can only say that from a theoretical point of view after
studying the kernel VFIO code. The only problem is after that, none else
device hotplug can happen. I know that is not a good thing because it
requires to restart the app, but better than breaking the app with a crash.

I will submit later today the patch for fixing the unplug issue. Maybe
someone can test that asap while I get some way for doing it.



> Thanks,
> Anatoly
>

  reply	other threads:[~2017-04-26  8:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20  7:23 [PATCH dpdk 0/5] ppc64/spapr: Attempt to use on POWER8 Alexey Kardashevskiy
2017-04-20  7:23 ` [PATCH dpdk 1/5] vfio/ppc64/spapr: Use correct structures for add/remove windows Alexey Kardashevskiy
2017-04-20  7:23 ` [PATCH dpdk 2/5] pci: Initialize common rte driver pointer Alexey Kardashevskiy
2017-04-24  9:28   ` Burakov, Anatoly
2017-04-20  7:24 ` [PATCH dpdk 3/5] RFC: bnx2x: Update firmware versions Alexey Kardashevskiy
2017-04-20  7:24 ` [PATCH dpdk 4/5] vfio: Do try setting IOMMU type if already set Alexey Kardashevskiy
2017-04-20 19:31   ` gowrishankar muthukrishnan
2017-04-21  8:54   ` Andrew Rybchenko
2017-04-26  7:50     ` Alexey Kardashevskiy
2017-04-26  8:27       ` Burakov, Anatoly
2017-04-26  8:45         ` Alejandro Lucero [this message]
2017-04-26  8:58           ` Burakov, Anatoly
2017-04-26 10:24             ` Alejandro Lucero
2017-04-20  7:24 ` [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map Alexey Kardashevskiy
2017-04-20  9:04   ` Jonas Pfefferle1
2017-04-20 13:25     ` Alexey Kardashevskiy
2017-04-20 14:22       ` Alexey Kardashevskiy
2017-04-20 15:15         ` Jonas Pfefferle1
2017-04-20 22:01           ` Alexey Kardashevskiy
2017-04-20 19:16         ` gowrishankar muthukrishnan
2017-04-21  3:42           ` Alexey Kardashevskiy
2017-04-21  8:43             ` Alexey Kardashevskiy
     [not found]               ` <OF6F33ED54.7950E1EF-ONC1258109.003295E3-C1258109.00333E2E@notes.na.collabserv.com>
2017-04-22  0:12                 ` Alexey Kardashevskiy
2017-04-24  9:40                   ` Burakov, Anatoly
2017-04-21  8:51             ` gowrishankar muthukrishnan
     [not found]             ` <OF45247CC5.192F9D29-ONC1258109.002D6497-C1258109.002F2868@notes.na.collabserv.com>
2017-04-21  8:59               ` Alexey Kardashevskiy
2017-04-22 21:11 ` [PATCH dpdk 0/5] ppc64/spapr: Attempt to use on POWER8 Olga Shern
2017-04-23 13:35   ` Alexey Kardashevskiy

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=CAD+H993pX8uM1sF09edRAuSJpxESnNCXA4+hGTNoJqEuZJvqHg@mail.gmail.com \
    --to=alejandro.lucero@netronome.com \
    --cc=JPF@zurich.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=anatoly.burakov@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=gowrishankar.m@in.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.