Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp505712pxj; Wed, 2 Jun 2021 04:52:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJziXV6iOBFEOI+cko46Ai9AyHzKrNYYNVzNbLGosk9h6hPM9oXjyCfOD3+ai3j9EwbPlT8f X-Received: by 2002:a92:de49:: with SMTP id e9mr10715335ilr.56.1622634728649; Wed, 02 Jun 2021 04:52:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622634728; cv=none; d=google.com; s=arc-20160816; b=B3rOQSPMnmHmA6+Q2mSLOjAt1hMTQ+O0YfLLH2hZLKs8sJPGREia6WPfgxQWbcgkwJ dhzCkNEFCz7z/1vAeH06iH8g55uVOgLZdLGZkNN9Bu5Ws+x18iX4RN9oJV2f0qeLup+w 2/xWOs6btnbe/RL05iDyM4uOqNJfTvJDTtUHWrP2FKYOSrESbaGPNMZ3o7LrXLKI04KY MVTkj5qyZ3Bn0hIWAAymE8pg1SMi/usE+kHRj80OioSGnmcwVUjSsVQnerPwY2LYPdIF oF5UhGJzFwgsxLxalvNidg+u9K+lj8LSAfNj6/L9RLc+bPdiV73GIKJkFkBehQnXar84 7PZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=5nGPXvUYHNxodE0Ypvpj9gD2XQPQaTAfkXM1FTd97uM=; b=Pji/gbYPPWDnlMIMDXC/cwbt+1DntKZPoBB4qw9lTt26YJ8fPHONEhMQlz29Su9h7+ c63lvtbagtXpoHs6o3rAr1MD+pMUIWOJCXRmfjiZF/mOVjB/pquNP1D5Rap7OdEp0640 oxtS7OXHSDXxfoaZQp0IIQZBGNDXkNeclFSn26n/Jvlxn9kN/66q1x5wrJ8IM2x6qqCA WLDMqJVyFtJR7+k3p37+rLgBCy3e/UugeU7QFOi55vYH2rdeWu/qE9cb3ljNe3sDGwQi RJFlOqIyQa0VYA+eEdYgbjccvLHCq8PXOlRP1Rfdz3/zEkGXV82Dhzio5nexW+PJXGx1 qezg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m5si22251596jat.27.2021.06.02.04.51.55; Wed, 02 Jun 2021 04:52:08 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232959AbhFBI7I (ORCPT + 99 others); Wed, 2 Jun 2021 04:59:08 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:45869 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231462AbhFBI7I (ORCPT ); Wed, 2 Jun 2021 04:59:08 -0400 Received: from [192.168.1.155] ([95.114.42.59]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MGi6k-1lafIq3Oew-00DpdX; Wed, 02 Jun 2021 10:56:54 +0200 Subject: Re: [RFC] /dev/ioasid uAPI proposal To: "Tian, Kevin" , LKML , Joerg Roedel , Jason Gunthorpe , Lu Baolu , David Woodhouse , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "Alex Williamson (alex.williamson@redhat.com)" , Jason Wang Cc: Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jacob Pan , Jean-Philippe Brucker , David Gibson , Kirti Wankhede , Robin Murphy References: From: "Enrico Weigelt, metux IT consult" Message-ID: Date: Wed, 2 Jun 2021 10:56:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: tl Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:3Mcq2cb/Ii9ywxMSUXsDQ9pb2+iZexTll119bJZkqKn6n/uAzeX vlBuy8gzAJoHwUTbHF/NioLbLGK4SyvZhqUm5yg9cGiQY7V3evXE44KhVXzMiMGt4/Cf+0t hvumRBsesWj4xZHsQkSA4vYDmw15qUKwS9PxlgOBBhlXZjg4HB0b/+dgqTxrCfE6CEVuKRJ 5GqKWS9lwAjodld6KcrWg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:3T0vIilwMWM=:yox9K5pXkfYHqVr3zyrSGk pGHofGYSVKITUO56tzDTQQeMUlqiezJiY1iU1N2g8mBSjXRkRt+qit8y3/H+qDaEx6FWUD+T8 2zxEo4s6fiqhOyQpOf/+BHispEZ03VAeISfUlEJKfkbx0+WjuNHEgeVRxX87ighdQNSgPyiqe PILXaXDH1s/q3xSA1qZxtRc+TXuVzZSyj1Ao92QnuDLbX4EbtQ319zNW1yhF4uuC7l+1bSrac IWdfwXu73ZKzhJCNW4czH/r58AyDTa/vELP2yx2cqMoHiRyhuxLlQtM+EBL3qmroRYzGoYeC9 oemgnJQKz8baqNs8M8Co5+2EPoSuDqCqpyEAwBU8g1itzuGflXO0f+KsrSjHAnUqF5/0/x3vI cqqFbSmyhFiO5UfQcV1zRJpzELKcdxjFCEZYPk9TPz09cIbdBOVqURnwMRB0ODmBHJanmCKKH XHmd3gq/QOWATPJVNXYOtnsgmxwIYMdMShNnrfKWSNKuj4YMT0R7JH2ZVa1B/zNfJrgZqwnUo GLmx9XbSg7JKS6nsTmdDqY= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27.05.21 09:58, Tian, Kevin wrote: Hi, > /dev/ioasid provides an unified interface for managing I/O page tables for > devices assigned to userspace. Device passthrough frameworks (VFIO, vDPA, > etc.) are expected to use this interface instead of creating their own logic to > isolate untrusted device DMAs initiated by userspace. While I'm in favour of having generic APIs for generic tasks, as well as using FDs, I wonder whether it has to be a new and separate device. Now applications have to use multiple APIs in lockstep. One consequence of that is operators, as well as provisioning systems, container infrastructures, etc, always have to consider multiple devices together. You can't just say "give workload XY access to device /dev/foo" anymore. Now you have to take care about scenarios like "if someone wants /dev/foo, he also needs /dev/bar"). And if that happens multiple times together ("/dev/foo and /dev/wurst, both require /dev/bar), leading to scenarios like the dev nodes are bind-mounted somewhere, you need to take care that additional devices aren't bind-mounted twice, etc ... If I understand this correctly, /dev/ioasid is a kind of "common supplier" to other APIs / devices. Why can't the fd be acquired by the consumer APIs (eg. kvm, vfio, etc) ? --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287