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.3 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 EC080C47094 for ; Tue, 8 Jun 2021 01:09:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF1F161073 for ; Tue, 8 Jun 2021 01:09:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231224AbhFHBLZ (ORCPT ); Mon, 7 Jun 2021 21:11:25 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:8064 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230209AbhFHBLX (ORCPT ); Mon, 7 Jun 2021 21:11:23 -0400 Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4FzXBQ5JNHzYrPB; Tue, 8 Jun 2021 09:06:38 +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; Tue, 8 Jun 2021 09:09:22 +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; Tue, 8 Jun 2021 09:09:21 +0800 Subject: Re: [RFC] /dev/ioasid uAPI proposal To: "Liu, Yi L" , 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" , "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: <9653f2a9-b6a0-86e8-19d4-53ab9079c49c@huawei.com> Date: Tue, 8 Jun 2021 09:09:01 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.185.220] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) 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/7 20:19, Liu, Yi L wrote: >> From: Shenming Lu >> Sent: Friday, June 4, 2021 10:03 AM >> >> 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. > > under new proposal, I think the page fault handler is also registered > per ioasid object. The difference compared with guest page table case > is there is no need to inject the fault to VM. Yeah. And there are some issues specific to the GPA address space case which have been discussed with Alex.. 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.3 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 8F2A2C47082 for ; Tue, 8 Jun 2021 01:09:42 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (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 431DB61073 for ; Tue, 8 Jun 2021 01:09:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 431DB61073 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 smtp2.osuosl.org (Postfix) with ESMTP id 09BE7402AB; Tue, 8 Jun 2021 01:09:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Mksy6gmOqD; Tue, 8 Jun 2021 01:09:38 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTP id B6F85400E0; Tue, 8 Jun 2021 01:09:37 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8CEE3C000D; Tue, 8 Jun 2021 01:09:37 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id E3A3AC0001 for ; Tue, 8 Jun 2021 01:09:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BB124403C7 for ; Tue, 8 Jun 2021 01:09:35 +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 KeERV46NmDgo for ; Tue, 8 Jun 2021 01:09:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by smtp4.osuosl.org (Postfix) with ESMTPS id 65456403C0 for ; Tue, 8 Jun 2021 01:09:31 +0000 (UTC) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4FzXBQ5JNHzYrPB; Tue, 8 Jun 2021 09:06:38 +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; Tue, 8 Jun 2021 09:09:22 +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; Tue, 8 Jun 2021 09:09:21 +0800 Subject: Re: [RFC] /dev/ioasid uAPI proposal To: "Liu, Yi L" , 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: <9653f2a9-b6a0-86e8-19d4-53ab9079c49c@huawei.com> Date: Tue, 8 Jun 2021 09:09:01 +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: Content-Language: en-US X-Originating-IP: [10.174.185.220] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500022.china.huawei.com (7.185.36.162) X-CFilter-Loop: Reflected Cc: Jean-Philippe Brucker , "Tian, Kevin" , "Alex Williamson \(alex.williamson@redhat.com\)" , "Raj, Ashok" , "kvm@vger.kernel.org" , Jonathan Corbet , Robin Murphy , LKML , Kirti Wankhede , "iommu@lists.linux-foundation.org" , David Gibson , Jason Gunthorpe , "wanghaibin.wang@huawei.com" , "Jiang, Dave" , David Woodhouse , Jason Wang 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/7 20:19, Liu, Yi L wrote: >> From: Shenming Lu >> Sent: Friday, June 4, 2021 10:03 AM >> >> 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. > > under new proposal, I think the page fault handler is also registered > per ioasid object. The difference compared with guest page table case > is there is no need to inject the fault to VM. Yeah. And there are some issues specific to the GPA address space case which have been discussed with Alex.. Thanks, Shenming _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu