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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E4714C433DB for ; Fri, 19 Mar 2021 13:42:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B22BF64F11 for ; Fri, 19 Mar 2021 13:42:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230050AbhCSNmC (ORCPT ); Fri, 19 Mar 2021 09:42:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230028AbhCSNlw (ORCPT ); Fri, 19 Mar 2021 09:41:52 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04754C06174A for ; Fri, 19 Mar 2021 06:41:52 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id v11so9156887wro.7 for ; Fri, 19 Mar 2021 06:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DAYPn6BONqpHEbUgtaq686MIszfpE7Ws+kMTTaVpKdw=; b=IOd4Cob2v4qwcVrJJUnC6ZJVxIF2WBZVUhabq0Mv+BS0jxbHyUnYBlGulXszdU4mh5 JXzpsK3jKuoU/S5b9nKYFRf5F0sT8Ih0u+BBZ97AbRXwrnLfybJJGTeRgA19XHDBH/6A EIDPKhijEx951g3qBOvaySlcB+XCF59BiLWj7FAAa+dfvbhhKPrkAChUBce435eNngqn R+HJqOzXYp0v+9UH9mxi/ExOXRx5qD4c7l8r5Po2L8As98VwmoUM9fKmxEPZfPe/fd7Q UbCXx9Q/ZuSWaZ1C6p/tiwNnPCGMuVJaU5azJ48KpQKEX3nEV8O7VaIWzhCFinZ0/Xoq OHoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DAYPn6BONqpHEbUgtaq686MIszfpE7Ws+kMTTaVpKdw=; b=HRCNMYe/Sz7+OaOKkI/NTEgB1DAmaIvNCXKtn1Y+4XEx1/OYZaQ2lyniy0PTVE6qHo aPLcxE6L8wQ5PZFRhzPJxhpr1p5G7hHTm1XrX3a7SOdFrbXrYZmxuyBbYXXVjpJuBrWN cMFCzOB45eT7x/OWwZJIY4l0B2UvuZRUYr3pEgKm64z+ppmp7kLsoaRyJXURw1Ri2Q0+ H8B61WCYOnkxvvOiHrfzusFV7cZHqPQ8jdWQhY+8gwhUjVtNvFfl6uIuehCwe7MpmAwD PoJEy62ELNVuw4UPJtQs9bndgN3Zm7mwSs31cn6aQQ80ILFERQfXQcK12WObqRKF6BpJ 4U6g== X-Gm-Message-State: AOAM530gSCeCcGWJ+uEbowZCOVTBHgJUHPGqa7ywADwDg9cMgDHxLR/E tYVya14/l9+yjTsjYIE4Bw1Gow== X-Google-Smtp-Source: ABdhPJyQGtsZyiZINsYu1PPARQsbLsQTm4cSQr/DP78vQm+uFeco8MqdIu7fVUjhkFhpApMilBcfpQ== X-Received: by 2002:adf:e5c4:: with SMTP id a4mr4678213wrn.174.1616161310724; Fri, 19 Mar 2021 06:41:50 -0700 (PDT) Received: from myrica ([2001:1715:4e26:a7e0:116c:c27a:3e7f:5eaf]) by smtp.gmail.com with ESMTPSA id l21sm6625021wmg.41.2021.03.19.06.41.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Mar 2021 06:41:50 -0700 (PDT) Date: Fri, 19 Mar 2021 14:41:32 +0100 From: Jean-Philippe Brucker To: Jason Gunthorpe Cc: Jacob Pan , LKML , Joerg Roedel , Lu Baolu , David Woodhouse , iommu@lists.linux-foundation.org, cgroups@vger.kernel.org, Tejun Heo , Li Zefan , Johannes Weiner , Jean-Philippe Brucker , Alex Williamson , Eric Auger , Jonathan Corbet , Raj Ashok , "Tian, Kevin" , Yi Liu , Wu Hao , Dave Jiang Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs Message-ID: References: <1614463286-97618-1-git-send-email-jacob.jun.pan@linux.intel.com> <1614463286-97618-6-git-send-email-jacob.jun.pan@linux.intel.com> <20210318172234.3e8c34f7@jacob-builder> <20210319124645.GP2356281@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210319124645.GP2356281@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote: > On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote: > > > Although there is no use for it at the moment (only two upstream users and > > it looks like amdkfd always uses current too), I quite like the > > client-server model where the privileged process does bind() and programs > > the hardware queue on behalf of the client process. > > This creates a lot complexity, how do does process A get a secure > reference to B? How does it access the memory in B to setup the HW? mm_access() for example, and passing addresses via IPC > Why do we need separation anyhow? SVM devices are supposed to be > secure or they shouldn't do SVM. Right Thanks, Jean