Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Cc:     baolu.lu@linux.intel.com,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Joerg Roedel <joro@8bytes.org>,
        David Woodhouse <dwmw2@infradead.org>,
        Alex Williamson <alex.williamson@redhat.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        Christoph Hellwig <hch@infradead.org>,
        Jonathan Cameron <jic23@kernel.org>,
        Eric Auger <eric.auger@redhat.com>
Subject: Re: [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID
To:     Jacob Pan <jacob.jun.pan@linux.intel.com>,
        "Tian, Kevin" <kevin.tian@intel.com>
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>
 <ae437be4-e633-e670-0e1f-d07b4364f651@linux.intel.com>
 <20191024214311.43d76a5c@jacob-builder>
 <AADFC41AFE54684AB9EE6CBC0274A5D19D5CDC60@SHSMSX104.ccr.corp.intel.com>
 <e950cde8-8cd9-6089-c833-23d2ffb539d1@linux.intel.com>
 <AADFC41AFE54684AB9EE6CBC0274A5D19D5D0FF0@SHSMSX104.ccr.corp.intel.com>
 <20191028154900.0be0a48f@jacob-builder>
From:   Lu Baolu <baolu.lu@linux.intel.com>
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-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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