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 F264CA09E4; Thu, 21 Jan 2021 16:00:27 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 945ED140E2B; Thu, 21 Jan 2021 16:00:27 +0100 (CET) Received: from out0-153.mail.aliyun.com (out0-153.mail.aliyun.com [140.205.0.153]) by mails.dpdk.org (Postfix) with ESMTP id 64ADF140E22 for ; Thu, 21 Jan 2021 16:00:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1611241223; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-Type; bh=BTfstFGQzNxPPaXg+MDmqGKZtEcLRlU3yN9TLvbKFfw=; b=UA9d9f50KTjpUbKaWoY/ow92nohWQ3/sO2BVSu+Bywxk4bEs397g0k/hthbKNIiV7T0+i+fuxrIBe70V0ZtrrevVJeaXI7ToH3zWbMtyVJT7z2JMzQjrlN9fNEthjljmFW6KVlrghlhE18Qh7MV9SrQ3MIT0D0l0cm1YlrlZepU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047188; MF=huawei.xhw@alibaba-inc.com; NM=1; PH=DS; RN=7; SR=0; TI=SMTPD_---.JNvjcW._1611241222; Received: from 30.43.72.173(mailfrom:huawei.xhw@alibaba-inc.com fp:SMTPD_---.JNvjcW._1611241222) by smtp.aliyun-inc.com(127.0.0.1); Thu, 21 Jan 2021 23:00:23 +0800 From: "=?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?=" To: Maxime Coquelin , ferruh.yigit@intel.com Cc: dev@dpdk.org, anatoly.burakov@intel.com, david.marchand@redhat.com, chenbo.xia@intel.com, grive@u256.net References: <68ecd941-9c56-4de7-fae2-2ad15bdfd81a@alibaba-inc.com> <1603381885-88819-1-git-send-email-huawei.xhw@alibaba-inc.com> <1603381885-88819-4-git-send-email-huawei.xhw@alibaba-inc.com> <18871462-4d25-302a-2716-99ebec65c3ac@alibaba-inc.com> <40e0702d-7847-9dc3-1904-03a7b8e92c2e@alibaba-inc.com> Message-ID: <8da8e9d0-0bfe-04f3-8635-fcc970fea228@alibaba-inc.com> Date: Thu, 21 Jan 2021 23:00:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <40e0702d-7847-9dc3-1904-03a7b8e92c2e@alibaba-inc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v5 3/3] PCI: don't use vfio ioctl call to access PIO resource 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" >> " >> >> I think that using inb/outb in the case of VFIO with IOMMU enabled won't >> work without cap_sys_rawio, and using it in the case of VFIO with IOMMU >> disabled just bypasses VFIO and so is not correct. > > Get your concern. > > PIO bar: > >     HW virtio on HW machine: any vendor implements hardware virtio > using PIO bar? I think this isn't right. And i dout if vfio doesn't > check rawio perssion in the syscall in this case. > >     Para virtio:  you have no choice to enable unsafe no-iommu mode.  > You must have RAWIO permission. Sorry. typo.  "you have no choice but to enable unsafe no-iommu mode. " > > so with PIO bar, the regression doesn't exist in real world. > > Btw, our virtio device is basically MMIO bar, either in hardware > machine or in pass-throughed virtual machine. > > > Do you mean we apply or abandon patch 3? I am both OK. The first > priority to me is to enable MMIO bar support. > >