Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5005085pxj; Wed, 12 May 2021 19:10:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxveKHPL3Kb0nqiW6z86r8XcNvJ2CAzKlIaMq94GPgNPQdTyOaa+5QJP3z0eVaIx7EDZZtW X-Received: by 2002:aca:1e07:: with SMTP id m7mr1182582oic.107.1620871809270; Wed, 12 May 2021 19:10:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620871809; cv=none; d=google.com; s=arc-20160816; b=PzxaWMIv7uVdfg4AAGIKAUkuxNywUE0bhXxCgC7DHwb9Q+o/VUM3X3AbV1DASWF+Pa rTF9qcRBXK0/DilHTFE2XSg9TRR8y+gQWYU4ADHU2/jlnZRiBeU/o7YtR0zqwX/2WMoz Xw+SOdaIiJcnt0an/CdOWZOZqHYvarhk5EvVvTWHkEpJbLPogkCgcMitz8Mwrw7ilH66 mYneyqUEphDrogNiRrpeyW9q+/qMF3/OGLQLgYtmwuljWtfDm5d3p6FLHU64lbYkmJhU ONUNa0MwnfkpkA7DBwp/Rk6oNVc8hbRzk4zKuRSousjCtj+1F27QJe+6ZWiVrVS/NPQL OVug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=GFaTyGHEIjvECtXSKGLpCWupU7L/xjhpByIIF4suaTY=; b=cr0U1DXwrcj/L2bTRlWaLTK6Cn12YhIR5QdCMb3G0n2sjMrKFgjLMRTmTiP2OwqBlx ozC796iw0kkN+EH0Kc2oBGGDkmNxNv9RVCqUPuYnsLOfb4y8dKBPjjCpOv6+xJ4Reyi9 TVOAsIEG7hjPgiozhHjFRi5QEMGAYZU8Om+oDwYp0VCyiVwAVtKqF1JXB/8oTIEz6wZF /MMRz3Lm3ymJZZkmAJqVckBdlkE6kxvXdUvvWWFrFaZna4AxE5kNOeLRkFgn/15Xstro 8Vg73Qmp8KQXnSbs2b5YoE4adEyZrT3GA8XHkCfVjq1jDnuBCs7CN589UcqKjdxwijzA LMhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s20si1777447otk.288.2021.05.12.19.09.55; Wed, 12 May 2021 19:10:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230017AbhEMCJn (ORCPT + 99 others); Wed, 12 May 2021 22:09:43 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:3737 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229630AbhEMCJm (ORCPT ); Wed, 12 May 2021 22:09:42 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FgZjx5xjqzpdrS; Thu, 13 May 2021 10:05:09 +0800 (CST) Received: from [10.67.102.118] (10.67.102.118) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Thu, 13 May 2021 10:08:28 +0800 Subject: Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio To: Jason Gunthorpe CC: Alex Williamson , , , References: <1618284983-55581-3-git-send-email-liulongfang@huawei.com> <20210415220137.GA1672608@nvidia.com> <10d53c5d-e6d5-a165-84b2-eaf8a3b7dcce@huawei.com> <20210419123314.GT1370958@nvidia.com> <00c4fa43-21fa-a48b-b95d-a2310ffab725@huawei.com> <20210420125957.GA1370958@nvidia.com> <20210420160457.6b91850a@x1.home.shazbot.org> <25d033e6-1cba-0da0-2ee7-03a14e75b8a5@huawei.com> <20210421121224.62382e5d@redhat.com> <6ea89655-31c5-233b-ca2a-fcc166b5597c@huawei.com> <20210512121053.GT1002214@nvidia.com> From: liulongfang Message-ID: <3eaa3114-81b6-1bd9-c7e6-cb1541389b58@huawei.com> Date: Thu, 13 May 2021 10:08:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210512121053.GT1002214@nvidia.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.118] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/5/12 20:10, Jason Gunthorpe wrote: > On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > >> Therefore, this method of limiting the length of the BAR >> configuration space can prevent unsafe operations of the memory. > > The issue is DMA controlled by the guest accessing the secure BAR > area, not the guest CPU. > > Jason > . > This secure BAR area is not presented to the Guest, which makes it impossible for the Guest to obtain the secure BAR area when establishing the DMA mapping of the configuration space. If the DMA controller accesses the secure BAR area, the access will be blocked by the SMMU. Thanks Longfang.