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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 2C92CC47082 for ; Tue, 1 Jun 2021 01:26:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 095D6610A1 for ; Tue, 1 Jun 2021 01:26:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232515AbhFAB2H (ORCPT ); Mon, 31 May 2021 21:28:07 -0400 Received: from mga06.intel.com ([134.134.136.31]:46622 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231714AbhFAB2G (ORCPT ); Mon, 31 May 2021 21:28:06 -0400 IronPort-SDR: lpTGoGBVGUM9poQk/cmuUYvIPSkoOzSNOgNxF5Xfn6d848uOCw/HgGJVcq8BnRxqas6yddK+Vw jn/UbTTEYtHg== X-IronPort-AV: E=McAfee;i="6200,9189,10001"; a="264636450" X-IronPort-AV: E=Sophos;i="5.83,238,1616482800"; d="scan'208";a="264636450" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2021 18:26:23 -0700 IronPort-SDR: 3ISgzlIM9qswXjZQDHBeANiitu0fX8s7d+7JTlBEqDv2NaJfFaUxOX4F6EkXR8+6aF44ke+Lvp 1iqskwpkwaAQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,238,1616482800"; d="scan'208";a="632703400" Received: from allen-box.sh.intel.com (HELO [10.239.159.105]) ([10.239.159.105]) by fmsmga006.fm.intel.com with ESMTP; 31 May 2021 18:26:19 -0700 Cc: baolu.lu@linux.intel.com, Jean-Philippe Brucker , "Tian, Kevin" , "Jiang, Dave" , "Raj, Ashok" , "kvm@vger.kernel.org" , Jonathan Corbet , David Woodhouse , Jason Wang , LKML , Kirti Wankhede , "Alex Williamson (alex.williamson@redhat.com)" , "iommu@lists.linux-foundation.org" , Robin Murphy , David Gibson Subject: Re: [RFC] /dev/ioasid uAPI proposal To: Liu Yi L , Jason Gunthorpe References: <20210528233649.GB3816344@nvidia.com> <20210531193157.5494e6c6@yiliu-dev> From: Lu Baolu Message-ID: <576ab03b-3f2b-512f-7c29-f489ed9576f6@linux.intel.com> Date: Tue, 1 Jun 2021 09:25:11 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210531193157.5494e6c6@yiliu-dev> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/31/21 7:31 PM, Liu Yi L wrote: > On Fri, 28 May 2021 20:36:49 -0300, Jason Gunthorpe wrote: > >> On Thu, May 27, 2021 at 07:58:12AM +0000, Tian, Kevin wrote: >> >>> 2.1. /dev/ioasid uAPI >>> +++++++++++++++++ [---cut for short---] >>> /* >>> * Allocate an IOASID. >>> * >>> * IOASID is the FD-local software handle representing an I/O address >>> * space. Each IOASID is associated with a single I/O page table. User >>> * must call this ioctl to get an IOASID for every I/O address space that is >>> * intended to be enabled in the IOMMU. >>> * >>> * A newly-created IOASID doesn't accept any command before it is >>> * attached to a device. Once attached, an empty I/O page table is >>> * bound with the IOMMU then the user could use either DMA mapping >>> * or pgtable binding commands to manage this I/O page table. >> Can the IOASID can be populated before being attached? > perhaps a MAP/UNMAP operation on a gpa_ioasid? > But before attaching to any device, there's no connection between an IOASID and the underlying IOMMU. How do you know the supported page sizes and cache coherency? The restriction of iommu_group is implicitly expressed as only after all devices belonging to an iommu_group are attached, the operations of the page table can be performed. Best regards, baolu