From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 54556A0547; Tue, 26 Oct 2021 17:25:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1AD7640E0F; Tue, 26 Oct 2021 17:25:12 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 98A45407FF for ; Tue, 26 Oct 2021 17:25:10 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10149"; a="290775718" X-IronPort-AV: E=Sophos;i="5.87,184,1631602800"; d="scan'208";a="290775718" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2021 08:25:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,184,1631602800"; d="scan'208";a="497385531" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga008.jf.intel.com with ESMTP; 26 Oct 2021 08:25:06 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 26 Oct 2021 08:25:05 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 26 Oct 2021 08:25:05 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 26 Oct 2021 08:25:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WFafZSW8iwRjYUl/4L/O5QNpY26uKQaiNKBCz9v5FI5sZcsn9dYNdrRYZXvYWSvJfYeKno6dljZPxbDlZNUWSsvxibA9fpnSAW28YZzdXDmz0rm7IAUH7Mnwib56arilnY4ID2ljkC6nwAxkPw0MMwHvQg0AqSTgVN/HHd5Q4mfswmsZ04XDY3FimFJ/PBIAfzsKH+L+/GY4iAEpu+MHIqiTisrNQIIDsCqyftg4/ardzergDXQi4v2N+YpLI9ThvJlOglbJIzhlYutVome/11A5ZhQh7R1PHW8LRNS/ZNJn+IoRN51HeLENRloFVAScd9QtTkDE/CtAdm9xoZrFBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4nKBDCHkHByY/iLZpmG4PighyyeXfZNEcaCZvxN4G54=; b=mHmjBg4SU1JtR/SmxLAFR1QIBXlb//8YVMMzyabGm5HP3L/jK/GN9Um8hKwUPDitDVenGUTlwEBP9A4GSrw9FWL3HQcdtZb0n2LHg+yxkeRVMe7qa5QbLUNFpJ81ePr7ubwpDKYCcBfbz+9Aoa7t141nkjgHKK+fw/hYJV07DHn4sUUvDTxftCQ8UHAuh2l1eiuMauBYDhF1jgEqINIKYDrnq/CQM3oynKTAyg2z9wQXcyADnDjLjFIxXvidAZLgnpJLBEOAfup4irFLZG0mMEaQqmeMFwHKEboxbaE08/6PbJe6BGS7BrWBLiMnCEJkqC15U2wsz2duwFQdmLLXsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4nKBDCHkHByY/iLZpmG4PighyyeXfZNEcaCZvxN4G54=; b=dVtnujn6BEXNswaLFlZ74+uckaz/Fd9aRvRjBtpdAMFIF5GeR5L8vAG/YcGz0Kjc2QC3RRQn/ePLN0sM3zI1EPwmDbSdThgymsV4Z4cSrLTYaCMCv32sD8RagLEfw06h1Ni7/Jprb4nqk5eCetCfI0fRzNkD8+Vv26tI4doztS4= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) by PH0PR11MB5078.namprd11.prod.outlook.com (2603:10b6:510:3e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Tue, 26 Oct 2021 15:25:01 +0000 Received: from PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::a80e:d881:3c58:9730]) by PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::a80e:d881:3c58:9730%3]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 15:25:01 +0000 From: "Burakov, Anatoly" To: "Ding, Xuan" , Maxime Coquelin , "dev@dpdk.org" , "david.marchand@redhat.com" , "Xia, Chenbo" CC: "Hu, Jiayu" References: <20211025203353.147346-1-maxime.coquelin@redhat.com> <6714a5cf-b0b9-e1a8-60c4-83904ef4b9b9@intel.com> Message-ID: <54529cf7-c048-0e00-ee61-8e9824818eb8@intel.com> Date: Tue, 26 Oct 2021 16:24:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 In-Reply-To: <6714a5cf-b0b9-e1a8-60c4-83904ef4b9b9@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DU2PR04CA0067.eurprd04.prod.outlook.com (2603:10a6:10:232::12) To PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) MIME-Version: 1.0 Received: from [192.168.1.10] (212.17.34.161) by DU2PR04CA0067.eurprd04.prod.outlook.com (2603:10a6:10:232::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.22 via Frontend Transport; Tue, 26 Oct 2021 15:24:59 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4bcc93d4-090c-49a8-a8a8-08d99894c707 X-MS-TrafficTypeDiagnostic: PH0PR11MB5078: X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3X6bF5Fla+XG4PRIHAGUchUcYp9jxFNG6kCYohnxc+C8x7Y7cOoDIO3wKqLrBFral10ODc5cFtJ/WQTfLgxSsblvu5rKjIvGnkS9XIC3y0a079yEW2gda5JpVwu5LUp5P9zocBnawaHnBzY8E5DH+iHRDgUY+I4pb/yfYw+9HqlAOuiTudDT+G2RsbucYEPQhfrL+eS/uDXqVQi95DuhWDgbRtizxvszK3atgoP033GGu3behhtodcCJKlNkDH3K4n+Y97XGunokFWodbl+bg+KKX0JsYh5eVBZL2vVpRNEvT90zk22FNKUJ6iTLKyIzgLR9NfSK16jXzw88w37rbPFpPKYXlNfSOrgkeitHb7lJllLNZ4mj6ElZBvlOENAW/JoupDZGjruYc+OxoFmr+mNG6QdmzwOvZ4/vvillg2a6LYqiDIbaqosEhXy+XjcSPIwyXDU0aybE8A0YyA2u/ph1tGChqgXvpAAz9X9AVllyVM2tCbvB83ujStsfhUJHbCgy/Ts/kYT87NOdm4l5bqlktTXmxA4/xcr3LuS2Evdq/dPV7wONVob5YIlnYzM+SYpoGoW2iW3zzECkJ2ohaFFpCS+GR0OmqALQVg8RJBfayijxL2/5NVYFA4tckF1K0Ht368IPm6+huFE1a9CJ+19qa4sfpiFqU/64u0g7W6JlDhZXEcGzy2wiWA2n85A/htgxWkQ+fUlI0X1ahOrJqwZKkouNZQUQx72MNhsGIv7bZI5ePk7xMP6+oYhXGNAuM65AHMrvMNyQzABRfvQaklsupZQMXlawlw6Ckz06ex7WW7eU8HrYSxjPUvZd1u0tD4nffWPU2NE9jOfdkWIgCw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5093.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6636002)(966005)(186003)(8936002)(16576012)(508600001)(66556008)(110136005)(107886003)(86362001)(38100700002)(956004)(66946007)(4326008)(66476007)(2616005)(6666004)(31686004)(53546011)(26005)(6486002)(5660300002)(8676002)(2906002)(82960400001)(36756003)(31696002)(316002)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WkwvVm9PUlkvSVZ2TG1VTHZpSnM1SXpOWVZ3VlF5Tm1wZlpPT05FWGFQVW9W?= =?utf-8?B?N0N6THc3ajFUa09ZN24ySHVFaVFSbFRUVHhXcCtjVUlkb0dkKzl2cSt2N0FU?= =?utf-8?B?OHJWSkM3QUdUaEFUYlRuU2dqWjlZTzltTTlmV1BzK2hWQ29XTmdNSURjV1pP?= =?utf-8?B?djRyeG9rcHhZSzJVS212czRKZVJzMmJrZXl5cnByZmhqelpCV0ZPUDhNRE1h?= =?utf-8?B?Um9RcTZPRm85QklXVzIzYmtPanhpVC84ZEtCN0RGS0FlbGN4cngwY3F0UjRH?= =?utf-8?B?L3pDQW9Yb2NCU3UyZ3RsaUJxQnNHcC9DbkRNWFh6a1dZcHZiR2cxVWJSR1U3?= =?utf-8?B?R0ZmSU1GTGI2OG1qOWZaZUVseTZqZ3kyV3lkVStXTGJMZ2t3MzlHVHpZQ3pW?= =?utf-8?B?dEpZdk1uWmFZNkxMRHFmSDJXbStyTklqSmhCUmorSEo2d2Q0VEJFYm5oZDNt?= =?utf-8?B?WkZ2cGRyKzc1OTkya2JBQURGczdyNEZhb1VnK2tUK2EyYm9nVDBBWGMwRFJm?= =?utf-8?B?U2xsbVlZWnJseVQzYk42MTZod0E1MElHaFBmekdqYWlqMTJYWDBZbVhDY1Fo?= =?utf-8?B?N3B6WkQ5RVRrWTlwUFBkUzYvbXo5VkNreWJ0bGdZcFdRNEJJbTBJRzMzWXNw?= =?utf-8?B?ZmhjRjQ0K3lsaFU3ZkpCYjBSWjZOQnBQd21wN0F0V0U1bWtZL1gvUG40OUxx?= =?utf-8?B?Kzd6d0I4TldDL0JkRWQyNm1iK1BZQzhmRXowQ0twSlJOZUdxRWpHVmhVamQy?= =?utf-8?B?L05xUWtERzQ2SlgrRE96bjZmVlBDYjlSNG1OVVpSZW1NRnA3cWZmeUdLZlQ5?= =?utf-8?B?V1FwUGtyK1V2bTNWVzlzNlcyZ3pzRG9IT21mRUJpYU9JcUF0WUZnZGxzMFMx?= =?utf-8?B?MUtoZGhyWVhqY05rOUxLQnRaNXhUejRqazNSSzhCYnUzTDJEVjJiZGdSazYz?= =?utf-8?B?WEZZRmIxUlZYak9jTnFuVmI3Yi9IK0ZVM2FTVU00THlSNllrN2duREwxaGFk?= =?utf-8?B?TEkvRUkvV3FCMFRWOGNBNnp6ZnJYNkgrQkRXVHlKMXNYTFhIY2k3Rnh2U1Br?= =?utf-8?B?VlZNVXJ1OG9mRWIzS0xLNkZHQmx0Z3VCaEFMbG52QVE2YzFwdnF1cjFvbE5t?= =?utf-8?B?MmpoZDZlYnFGMVNZeDM1Z05hdmltTE0zLzdwc3hVODlEMys0MHZ0d0xuVzV4?= =?utf-8?B?SUFNM3N3djdOVUN6THkxWEUxL2dqQjdaOTNYT0EyYVhUZmxoS2xqRWhqNTNu?= =?utf-8?B?WE5GVTh0VjUwVzVra3p2aGwrRXJ5ZGhiSGI3Y3R2YVhDWDBRY2dVSGNJQzNy?= =?utf-8?B?MDd5SUplNzRoc1E4TXJSek5acEE2VlVhQnYxaUUyR0lQbkxWTUQrQTV1RGk4?= =?utf-8?B?R3llQjk2TFhIL0hVMUxPVnRoRDJMazVVSjF3SEI4OXNsbk52UW4waE5pMTFQ?= =?utf-8?B?OUVoRkF6VHlwWVJkdkFsMjljVzlIb3l2SHcyK09YOFZ4OTc1WURJeFJhU3k1?= =?utf-8?B?cmlrNkNjb2JEZldKZ2RLUm50Ujg3R0JpTmExblQ2T3dMcTRhT1FDS2ZpRHQ4?= =?utf-8?B?Q1pFQXlJeTExdXlMSFFQSnpDT204LzdNKzQ1UHhWbzl4c1FKMGx6MUQ3THE2?= =?utf-8?B?ZnVjaFMxVGhjeW44Qk9FczlRemIrS0ZWbDZvYnorR0hFODV2NHVnU1VHNXVE?= =?utf-8?B?enk5eGJSWWxKQllDZHpuM2FSMkhIbnltdWJxNW11UmpwUDBWeHBKeVNET2Zz?= =?utf-8?B?WTlTRzB6YkE0ajhUR2o5VjlQTXdHcHAvci9CTWVYWGdHdm9tTjJsT0NSK2l1?= =?utf-8?B?cUl4OGhBcFBUQVlDajZEZEFLdHVTaWRsS3c3U2d1YzFWQnJDQVB0QUVSRVdZ?= =?utf-8?B?MEpHSmFVK1ZJZXlkNVpVdUp2MG9ZK2k5Mjlaa3pQTjBZa25qUkxSYTl0eHZX?= =?utf-8?B?VytSVEx0Z0p5TDIvV1FPdXE4OGppWm4yZElLY2ZiTGYwVjdEVi9STUM3NWx5?= =?utf-8?B?OGJGdWZHMjVEREo3empDaSswTHBhcWd1NGU2NVFCMG5STmRheERMQTN5aExz?= =?utf-8?B?NEt1czJidU9BaHFLc2NwVHBBOFg5ZmZSazIvanAva0F4SjZacmdsbEVCVkJS?= =?utf-8?B?K1BjR3lvZzFwZ3VYYk5WTHZaTUhZTG00MUEzL2xOL0dLR2p0ZDFCNEYrbTZ1?= =?utf-8?B?T1N6RFRVbGhya1ZUNW5uY2tuTVlDWEcwdXYrdXpkd3VaOFZOZUZ1OEE1cWIy?= =?utf-8?Q?ZLOHTOZwFLxDTAGCYsvuMQU+Vs9qNZ+sjjJM26QJhE=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 4bcc93d4-090c-49a8-a8a8-08d99894c707 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5093.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2021 15:25:01.6483 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: odl9+KLRYfXBgGqrlXuVLJrQMgx9ne7ug70dnGvBcexqy/CdJQ6DcsSJ9uBMOOnCSqy/PfeouWEmGm7V2vfqWpwViyU+I7vW4Bt6r0yn/ak= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5078 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] vhost: fix async DMA map X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 26-Oct-21 11:58 AM, Burakov, Anatoly wrote: > On 26-Oct-21 11:27 AM, Ding, Xuan wrote: >> Hi, >> >>> -----Original Message----- >>> From: Maxime Coquelin >>> Sent: Tuesday, October 26, 2021 5:49 PM >>> To: Ding, Xuan ; dev@dpdk.org; >>> david.marchand@redhat.com; Xia, Chenbo >>> Cc: Burakov, Anatoly >>> Subject: Re: [PATCH] vhost: fix async DMA map >>> >>> >>> >>> On 10/26/21 10:49, Ding, Xuan wrote: >>>> Hi Maxime, >>>> >>>>> -----Original Message----- >>>>> From: Maxime Coquelin >>>>> Sent: Tuesday, October 26, 2021 2:53 PM >>>>> To: Ding, Xuan ; dev@dpdk.org; >>>>> david.marchand@redhat.com; Xia, Chenbo >>>>> Cc: Burakov, Anatoly >>>>> Subject: Re: [PATCH] vhost: fix async DMA map >>>>> >>>>> >>>>> >>>>> On 10/26/21 04:07, Ding, Xuan wrote: >>>>>> Hi Maxime, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Maxime Coquelin >>>>>>> Sent: Tuesday, October 26, 2021 4:47 AM >>>>>>> To: dev@dpdk.org; david.marchand@redhat.com; Xia, Chenbo >>>>>>> ; Ding, Xuan >>>>>>> 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 >>>>>>>> --- >>>>>>>>      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. >>>>> >>>>> Ok, then I think we can just remove the async DMA map. >>>>> >>>>>>> >>>>>>> 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? >>>>> >>>>> No suggestion, I was just explaining that at the only place where >>>>> DMA map were done, mapping errors were properly handled and >>> propagated. >>>> >>>> What about just setting async_copy to false, and allow switching to >>>> sync >>> path. >>>> >>>>> >>>>>>> >>>>>>> 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. >>>>> >>>>> I would think we don't care if DMA unmap fails, we can just do the >>>>> same >>>>> as what you do for DMA map, i.e. just ignore the error. >>>> >>>> Get your idea, we can do the same as DMA map, and in this way >>> dma_map_status flag can be removed. >>>> >>>>> >>>>> Thanks to this discussion, I have now more concerns on how it works. I >>>>> think we have a problem here in case of DMA device hotplug, that >>>>> device >>>>> could miss the necessary map entries from Vhost if no VFIO devices >>>>> were >>>>> attached at VHST_USER_SET_MEM_TABLE time. How would you handle >>> that >>>>> case? >>>> >>>> DMA device is uncore, so I don't see the  hotplug issue here. >>> >>> I'm not sure what 'uncore' is, I suppose you mean your device cannot be >>> physically added/removed to the system. >> >> Yes, we are at the same understanding. >> >>> >>> I was not clear enough in my question. I meant that for example, the >>> application is started and the Vhost port is created. Then, the DMA >>> device is bound to VFIO, and probed by the DPDK application. Finally, >>> the application register the DMA device as an async channel in Vhost. >>> >>> I think it will not work as the SET_MEM_TABLE will already have >>> happened, so the guest memory won't be mapped in the VFIO container. >> >> Assuming the DMA device supports hotplug, this situation was not >> actually took into consideration, and maybe the handling should be >> added in app, with an event callback. >> >>> >>> Do you have the same understanding? >>> >>>> I will have another patch containing compatibility with sync path, and >>> async_map_status flag will be removed. >>>> Hope to get your insights. >>> >>> What do you mean by compatibility with sync path? >> >> I mean whatever DMA map succeeds or fails, we return 0 so as not to >> prevent >> SET_EM_TABLE. >> >>> >>> Thanks for taking care of the async map status removal. >> >> Found a tricky point for removing dma_map_status flag, currently DMA >> unmap API will directly access the vfio_config, >> And if without dma_map_status, we cannot get rte_errno at this moment. > > This is a bug in VFIO API. We always assume VFIO type is valid, but it > is only valid whenever 1) VFIO support is detected at startup, and 2) we > assign at least one device to VFIO. If VFIO was detected but no devices > were assigned, the VFIO type will not be assigned, and the pointer will > be NULL. In this case, we should not attempt any unmaps, because there > are no active devices. > > I'll submit a patch to fix this, thanks for catching this issue! Hi Xuan/Maxime, It would be great if you could test and confirm that this patch fixes the segfault: http://patches.dpdk.org/project/dpdk/patch/8079312ba39435a0ac92e084cc1a3fe291008a47.1635254797.git.anatoly.burakov@intel.com/ -- Thanks, Anatoly