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 9447AC47083 for ; Wed, 2 Jun 2021 08:57:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E750613DB for ; Wed, 2 Jun 2021 08:57:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232958AbhFBI7I (ORCPT ); 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-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: kvm@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