Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3983893pxj; Tue, 8 Jun 2021 03:46:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTAHVmqwOO/5fLdRhPXA9ggK87Fq9qkeKo5Gir2mLF/lTF49JYJdSzF0Gg/WgaRzoczOnK X-Received: by 2002:aa7:cc97:: with SMTP id p23mr24394404edt.372.1623149198182; Tue, 08 Jun 2021 03:46:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623149198; cv=none; d=google.com; s=arc-20160816; b=rFrU9y1PQyv+r6RHsgeB1NmYmD+XrdzgN2czA1cAS1HEnumz8g2S+mXQf3zrX1WYYl tYVphECtTNgYYdSh++Rk+OeA8JD7gUU2gtNle1yVjpWx3jOvFh83PpKgSMwBwyQcxQeO 2k0zC1vsptHU5MWr5y71o3Q4j0mSbgqp0wdVG6h78iwjNBt07ih3s1FJaMzHMbM8Ucu7 VQzO+gTCx775wzIzWJyC8EzGRUrUBLRB0BOCXn946A/xD0KIV2NDpVHTVkDzY8FVJ9iH kWJGd2LBU9g77hVgpxVvLpVC8S/1Z0WjTWIJi5QuXaMbsmwfdwIMnwsimNqctYzxJWQ1 zXiA== 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=iOYsbYE4J20RuBr6awgflS/E1codesJvnhSBcahktcM=; b=DKYY5D8LBQnxjAopppaO5EIxv+BwD1U3quUHCD2eL9g7Z7HiOVLGh89RFOmi9VwGvx Jw1q4SFaViM4BFZcqtg1C6mxxEsm14yGmVyryQgcjcfvAFZKB14jOZpMjJbbFpSm6/Fb im30MhK5MLyiY8sni4El0tWQ8UdKKIs9/sHotONn+xgOzjq5xKP3XOUIk+7SrGWaiw8N zbNP0pBcGVNOQxerVLoX1/RJoYKy3pJ5QiEp39qU3zboGEIGEJPhQsP6JwpHp8PcqT9V bVgZDHUEodl7sZYedMNBAuBA1coEVPwAqdUQ7RiJLoH/etI0UBPgkPKrLoOuqbh56rS0 H2Aw== 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 h93si16833641edd.605.2021.06.08.03.46.14; Tue, 08 Jun 2021 03:46:38 -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 S231629AbhFHKqD (ORCPT + 99 others); Tue, 8 Jun 2021 06:46:03 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:34329 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231262AbhFHKqC (ORCPT ); Tue, 8 Jun 2021 06:46:02 -0400 Received: from [192.168.1.155] ([77.7.0.189]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MnJdC-1l7e5D1hvo-00jJJM; Tue, 08 Jun 2021 12:43:43 +0200 Subject: Re: [RFC] /dev/ioasid uAPI proposal To: Jason Gunthorpe Cc: "Tian, Kevin" , LKML , Joerg Roedel , Lu Baolu , 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" , Jacob Pan , Jean-Philippe Brucker , David Gibson , Kirti Wankhede , Robin Murphy References: <20210602172424.GD1002214@nvidia.com> <20210604123054.GL1002214@nvidia.com> From: "Enrico Weigelt, metux IT consult" Message-ID: <329fcd72-605a-fc10-1a8d-c3f2ac3be9a1@metux.net> Date: Tue, 8 Jun 2021 12:43:38 +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: <20210604123054.GL1002214@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: tl Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:kQlbcYVyqh7Kv3mxj3JGjk3dxcaEReaRMO1wJlQyxPkwqc3rlNB ty1P4s3Q1U8YMBl+PAGTd/B9xN3luktYAJUvcIm8MxNrn5Ufw3QW/pOSLFBXCidANQm2vOL Kf0ipNSyGmyjvOYlXaOs+iavgR+8to7ozNqxLBThWjyjeMPtyrDyKl4eF6lXS34Ejofrm6p wfyAMKuEHX4+5ky7Fwr4A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:nhyYPjt/oTs=:181063X6GaNOTval4U+P8Y cwsH0SmjAvrMHg8eLaYi+NgNCkjBaK49pcjziRRbc2+BTBWboMP1G/J6UGA1JZO4o0rkgiJRu js1Wg22BcB3fVTdJ8XE8KwKizdDPS/mUiTNloNqCDjgMVH0vBodTGeko3MzQ+1K2pbo4PxVqY pacCRkNxVyN4T88mjozcEpKiSYPcf4I29DPsjgKlvb+2dX1w01/bpnmZYZoApd7H9elPk1jYf FA/7iRSaojlhbDSqWViQX0cY6iufNvofS2ydC4paMpcH7mUXEPmNaKzxdw+io8RzhbL8pO+3K 4TRWLInFEwbidBxYATrioZTqZ0N4hpCp/SvYDIfcNHiZjug8V0s7MpVr/6AdAPnHjSUXxAwHU f3BBAibd9lz3HbL12eZR4kIAFZDAYovq6GU08s1DtCbTzhUJirHdNHyixNjMC0yr7JmjWVv4k EkfU+sMCbj+4vxIa7lW+wuha41v3jnKCkDRiUIah6CNkFHkFkHddfO1LO8xkBbrN0KGw7hQZb pc4pd+imbUHacOaBdIOXCQ= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04.06.21 14:30, Jason Gunthorpe wrote: Hi, > Containers already needed to do this today. Container orchestration is > hard. Yes, but I hate to see even more work upcoming here. > Yes, /dev/ioasid shouldn't do anything unless you have a device to > connect it with. In this way it is probably safe to stuff it into > every container. Okay, if we can guarantee that, I'm completely fine. >>> Having FDs spawn other FDs is pretty ugly, it defeats the "everything >>> is a file" model of UNIX. >> >> Unfortunately, this is already defeated in many other places :( >> (I'd even claim that ioctls already break it :p) > > I think you are reaching a bit :) > >> It seems your approach also breaks this, since we now need to open two >> files in order to talk to one device. > > It is two devices, thus two files. Two separate real (hardware) devices or just two logical device nodes ? --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