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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 B8E4DCA9EC0 for ; Tue, 29 Oct 2019 02:25:19 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7F97C21479 for ; Tue, 29 Oct 2019 02:25:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F97C21479 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 46F08E5E; Tue, 29 Oct 2019 02:25:19 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 97975E1E for ; Tue, 29 Oct 2019 02:25:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38DC042D for ; Tue, 29 Oct 2019 02:25:18 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2019 19:25:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,242,1569308400"; d="scan'208";a="224826095" Received: from allen-box.sh.intel.com (HELO [10.239.159.136]) ([10.239.159.136]) by fmsmga004.fm.intel.com with ESMTP; 28 Oct 2019 19:25:15 -0700 Subject: Re: [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID To: Jacob Pan , "Tian, Kevin" References: <1571946904-86776-1-git-send-email-jacob.jun.pan@linux.intel.com> <1571946904-86776-4-git-send-email-jacob.jun.pan@linux.intel.com> <20191024214311.43d76a5c@jacob-builder> <20191028154900.0be0a48f@jacob-builder> From: Lu Baolu Message-ID: <0d8bd9c3-4e01-ab12-8671-ff25a4821ed7@linux.intel.com> Date: Tue, 29 Oct 2019 10:22:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191028154900.0be0a48f@jacob-builder> Content-Language: en-US Cc: "Raj, Ashok" , Jean-Philippe Brucker , "iommu@lists.linux-foundation.org" , LKML , Alex Williamson , David Woodhouse , Jonathan Cameron X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Hi, On 10/29/19 6:49 AM, Jacob Pan wrote: >>>> I'm not sure whether tying above logic to SVA is the right >>>> approach. If vcmd interface doesn't work, the whole SM mode >>>> doesn't make sense which is based on PASID-granular protection >>>> (SVA is only one usage atop). If the only remaining usage of SM >>>> is to map gIOVA using reserved PASID#0, then why not disabling SM >>>> and just fallback to legacy mode? >>>> >>>> Based on that I prefer to disabling the SM mode completely (better >>>> through an interface), and move the logic out of CONFIG_INTEL_ >>>> IOMMU_SVM >>>> >>> Unfortunately, it is dangerous to disable SM after boot. SM uses >>> different root/device contexts and pasid table formats. Disabling SM >>> after boot requires changing above from SM format into legacy >>> format. >> You are correct. >> >>> Since ioasid registration failure is a rare case. How about moving >>> this part of code up to the early stage of intel_iommu_init() and >>> returning error if hardware present vcmd capability but software >>> fails to register a custom ioasid allocator? >>> >> It makes sense to me. >> > sounds good to me too, the earlier the less to clean up. Actually, we even could return error directly and abort the iommu initialization. The registration of custom ioasid allocator fails only when memory runs out or software is buggy. In either cases, we should abort iommu initialization. Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu