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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 61511C2D0A3 for ; Tue, 3 Nov 2020 14:03:25 +0000 (UTC) Received: from hemlock.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 ABF1522264 for ; Tue, 3 Nov 2020 14:03:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABF1522264 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 14EC2873AA; Tue, 3 Nov 2020 14:03:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVw8e5dksGCi; Tue, 3 Nov 2020 14:03:22 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id D0970870CE; Tue, 3 Nov 2020 14:03:22 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B0EC6C0889; Tue, 3 Nov 2020 14:03:22 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B7C13C0051 for ; Tue, 3 Nov 2020 14:03:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 9CB8386C5A for ; Tue, 3 Nov 2020 14:03:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iumNDGX24vWz for ; Tue, 3 Nov 2020 14:03:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by whitealder.osuosl.org (Postfix) with ESMTPS id 1134986C4D for ; Tue, 3 Nov 2020 14:03:21 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id A00FD433; Tue, 3 Nov 2020 15:03:19 +0100 (CET) Date: Tue, 3 Nov 2020 15:03:18 +0100 From: "joro@8bytes.org" To: Jason Gunthorpe Subject: Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs Message-ID: <20201103140318.GL22888@8bytes.org> References: <20201103095208.GA22888@8bytes.org> <20201103125643.GN2620339@nvidia.com> <20201103131852.GE22888@8bytes.org> <20201103132335.GO2620339@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201103132335.GO2620339@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: "jean-philippe@linaro.org" , "Tian, Kevin" , "Raj, Ashok" , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "stefanha@gmail.com" , Jason Wang , "Michael S. Tsirkin" , "Sun, Yi Y" , "alex.williamson@redhat.com" , "Wu, Hao" , "Tian, Jun J" 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 Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote: > Userspace needs fine grained control over the composition of the page > table behind the PASID, 1:1 with the mm_struct is only one use case. VFIO already offers an interface for that. It shouldn't be too complicated to expand that for PASID-bound page-tables. > Userspace needs to be able to handle IOMMU faults, apparently Could be implemented by a fault-fd handed out by VFIO. > The Intel guys had a bunch of other stuff too, looking through the new > API they are proposing for vfio gives some flavour what they think is > needed.. I really don't think that user-space should have to deal with details like PASIDs or other IOMMU internals, unless absolutly necessary. This is an OS we work on, and the idea behind an OS is to abstract the hardware away. Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu