DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ding, Xuan" <xuan.ding@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"Xia, Chenbo" <chenbo.xia@intel.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: [dpdk-dev] [PATCH] vhost: fix async DMA map
Date: Tue, 26 Oct 2021 02:07:34 +0000	[thread overview]
Message-ID: <BN9PR11MB5513EBFA894DEC05BE4C5EE8E7849@BN9PR11MB5513.namprd11.prod.outlook.com> (raw)
In-Reply-To: <fb5ddef6-6bfd-8f05-6612-7e2a931e1a8b@redhat.com>

Hi Maxime,

>-----Original Message-----
>From: Maxime Coquelin <maxime.coquelin@redhat.com>
>Sent: Tuesday, October 26, 2021 4:47 AM
>To: dev@dpdk.org; david.marchand@redhat.com; Xia, Chenbo
><chenbo.xia@intel.com>; Ding, Xuan <xuan.ding@intel.com>
>Subject: Re: [PATCH] vhost: fix async DMA map
>
>Hi Xuan,
>
>On 10/25/21 22:33, Maxime Coquelin wrote:
>> This patch fixes possible NULL-pointer dereferencing
>> reported by Coverity and also fixes NUMA reallocation
>> of the async DMA map.
>>
>> Fixes: 7c61fa08b716 ("vhost: enable IOMMU for async vhost")
>>
>> Coverity issue: 373655
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>>   lib/vhost/vhost_user.c | 45 +++++++++++++++++++-----------------------
>>   1 file changed, 20 insertions(+), 25 deletions(-)
>>
>
>I posted this patch to fix the issue reported by Coverity and also other
>issue on NUMA realloc that I found at the same time. But I wonder
>whether all this async_map_status is needed.

Thanks for your fix! I can help to review and test the patch later.

I add the async_map_status in v2 for compatibility. Some DMA device,
like DSA, may use kernel idxd driver only. If there is no device bound to
DPDK vfio and kernel vfio module is modprobed to ensure rte_vfio_is_enabled() is true,
we will unavoidably do DMA map/unmap and it will fail.

Therefore, the dma_map_status here is used to filter this situation by preventing
unnecessary DMA unmap.

>
>Indeed, if the only place where we DMA map is in
>vhost_user_mmap_region(). If it fails, the error is propagated, the mem
>table are freed and NACK is replied to the master. IOW, the device will
>be in an unusable state.

I agree with you, this is the place I consider right to do DMA map
because we also do SW mapping here, any suggestions?

>
>Removing the async DMA map will simplify a lot the code, do you agree to
>remove it or there is something I missed?

See above. Indeed, it adds a lot of code. But we can't know the driver for
each device in vhost lib, or we can only restrict the user to bind some devices
to DPDK vfio if async logic needed.

>
>Thanks,
>Maxime


  reply	other threads:[~2021-10-26  2:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 20:33 Maxime Coquelin
2021-10-25 20:47 ` Maxime Coquelin
2021-10-26  2:07   ` Ding, Xuan [this message]
2021-10-26  6:52     ` Maxime Coquelin
2021-10-26  8:49       ` Ding, Xuan
2021-10-26  9:49         ` Maxime Coquelin
2021-10-26 10:27           ` Ding, Xuan
2021-10-26 10:58             ` Burakov, Anatoly
2021-10-26 15:24               ` 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=BN9PR11MB5513EBFA894DEC05BE4C5EE8E7849@BN9PR11MB5513.namprd11.prod.outlook.com \
    --to=xuan.ding@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.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).