From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A119C47097 for ; Fri, 4 Jun 2021 02:03:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3711460FE9 for ; Fri, 4 Jun 2021 02:03:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230033AbhFDCFA (ORCPT ); Thu, 3 Jun 2021 22:05:00 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:4466 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbhFDCE6 (ORCPT ); Thu, 3 Jun 2021 22:04:58 -0400 Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Fx5ZJ2cJgzYqJ4; Fri, 4 Jun 2021 10:00:24 +0800 (CST) Received: from dggpemm500022.china.huawei.com (7.185.36.162) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 10:03:09 +0800 Received: from [10.174.185.220] (10.174.185.220) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 10:03:08 +0800 Subject: Re: [RFC] /dev/ioasid uAPI proposal To: Jacob Pan CC: Jason Gunthorpe , Lu Baolu , "Tian, Kevin" , LKML , Joerg Roedel , David Woodhouse , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "Alex Williamson (alex.williamson@redhat.com)" , Jason Wang , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jean-Philippe Brucker , David Gibson , Kirti Wankhede , Robin Murphy , Zenghui Yu , "wanghaibin.wang@huawei.com" References: <01fe5034-42c8-6923-32f1-e287cc36bccc@linux.intel.com> <20210601173323.GN1002214@nvidia.com> <23a482f9-b88a-da98-3800-f3fd9ea85fbd@huawei.com> <20210603111914.653c4f61@jacob-builder> From: Shenming Lu Message-ID: Date: Fri, 4 Jun 2021 10:03:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <20210603111914.653c4f61@jacob-builder> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.185.220] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500022.china.huawei.com (7.185.36.162) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/6/4 2:19, Jacob Pan wrote: > Hi Shenming, > > On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu > wrote: > >> On 2021/6/2 1:33, Jason Gunthorpe wrote: >>> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote: >>> >>>> The drivers register per page table fault handlers to /dev/ioasid which >>>> will then register itself to iommu core to listen and route the per- >>>> device I/O page faults. >>> >>> I'm still confused why drivers need fault handlers at all? >> >> Essentially it is the userspace that needs the fault handlers, >> one case is to deliver the faults to the vIOMMU, and another >> case is to enable IOPF on the GPA address space for on-demand >> paging, it seems that both could be specified in/through the >> IOASID_ALLOC ioctl? >> > I would think IOASID_BIND_PGTABLE is where fault handler should be > registered. There wouldn't be any IO page fault without the binding anyway. Yeah, I also proposed this before, registering the handler in the BIND_PGTABLE ioctl does make sense for the guest page faults. :-) But how about the page faults from the GPA address space (it's page table is mapped through the MAP_DMA ioctl)? From your point of view, it seems that we should register the handler for the GPA address space in the (first) MAP_DMA ioctl. > > I also don't understand why device drivers should register the fault > handler, the fault is detected by the pIOMMU and injected to the vIOMMU. So > I think it should be the IOASID itself register the handler. Yeah, and it can also be said that the provider of the page table registers the handler (Baolu). Thanks, Shenming From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A2CDC47082 for ; Fri, 4 Jun 2021 02:03:20 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B1A3160FE9 for ; Fri, 4 Jun 2021 02:03:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1A3160FE9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 744FA6F93B; Fri, 4 Jun 2021 02:03:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjy2yLy3ifUT; Fri, 4 Jun 2021 02:03:18 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTP id 416D560AE1; Fri, 4 Jun 2021 02:03:18 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1A2AEC000E; Fri, 4 Jun 2021 02:03:18 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 45727C0001 for ; Fri, 4 Jun 2021 02:03:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1B6A240694 for ; Fri, 4 Jun 2021 02:03:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynLZUIaa3VS8 for ; Fri, 4 Jun 2021 02:03:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by smtp4.osuosl.org (Postfix) with ESMTPS id 752C14068F for ; Fri, 4 Jun 2021 02:03:14 +0000 (UTC) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Fx5ZJ2cJgzYqJ4; Fri, 4 Jun 2021 10:00:24 +0800 (CST) Received: from dggpemm500022.china.huawei.com (7.185.36.162) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 10:03:09 +0800 Received: from [10.174.185.220] (10.174.185.220) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 10:03:08 +0800 Subject: Re: [RFC] /dev/ioasid uAPI proposal To: Jacob Pan References: <01fe5034-42c8-6923-32f1-e287cc36bccc@linux.intel.com> <20210601173323.GN1002214@nvidia.com> <23a482f9-b88a-da98-3800-f3fd9ea85fbd@huawei.com> <20210603111914.653c4f61@jacob-builder> From: Shenming Lu Message-ID: Date: Fri, 4 Jun 2021 10:03:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <20210603111914.653c4f61@jacob-builder> Content-Language: en-US X-Originating-IP: [10.174.185.220] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500022.china.huawei.com (7.185.36.162) X-CFilter-Loop: Reflected Cc: "kvm@vger.kernel.org" , Jason Wang , Kirti Wankhede , Jean-Philippe Brucker , "Jiang, Dave" , "Raj, Ashok" , Jonathan Corbet , Jason Gunthorpe , "wanghaibin.wang@huawei.com" , "Tian, Kevin" , "Alex Williamson \(alex.williamson@redhat.com\)" , David Gibson , David Woodhouse , LKML , "iommu@lists.linux-foundation.org" , Robin Murphy X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021/6/4 2:19, Jacob Pan wrote: > Hi Shenming, > > On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu > wrote: > >> On 2021/6/2 1:33, Jason Gunthorpe wrote: >>> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote: >>> >>>> The drivers register per page table fault handlers to /dev/ioasid which >>>> will then register itself to iommu core to listen and route the per- >>>> device I/O page faults. >>> >>> I'm still confused why drivers need fault handlers at all? >> >> Essentially it is the userspace that needs the fault handlers, >> one case is to deliver the faults to the vIOMMU, and another >> case is to enable IOPF on the GPA address space for on-demand >> paging, it seems that both could be specified in/through the >> IOASID_ALLOC ioctl? >> > I would think IOASID_BIND_PGTABLE is where fault handler should be > registered. There wouldn't be any IO page fault without the binding anyway. Yeah, I also proposed this before, registering the handler in the BIND_PGTABLE ioctl does make sense for the guest page faults. :-) But how about the page faults from the GPA address space (it's page table is mapped through the MAP_DMA ioctl)? From your point of view, it seems that we should register the handler for the GPA address space in the (first) MAP_DMA ioctl. > > I also don't understand why device drivers should register the fault > handler, the fault is detected by the pIOMMU and injected to the vIOMMU. So > I think it should be the IOASID itself register the handler. Yeah, and it can also be said that the provider of the page table registers the handler (Baolu). Thanks, Shenming _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu