Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <51640965-4196-4da1-88b4-cb0e406931f3@intel.com>
Date:   Tue, 28 Nov 2023 14:01:59 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/6] iommufd: Add IOMMU_HWPT_INVALIDATE
Content-Language: en-US
To:     Nicolin Chen <nicolinc@nvidia.com>,
        "Tian, Kevin" <kevin.tian@intel.com>
CC:     "joro@8bytes.org" <joro@8bytes.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "jgg@nvidia.com" <jgg@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
        "chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
        "yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
        "peterx@redhat.com" <peterx@redhat.com>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "lulu@redhat.com" <lulu@redhat.com>,
        "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
        "joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
        "Zeng, Xin" <xin.zeng@intel.com>,
        "Zhao, Yan Y" <yan.y.zhao@intel.com>
References: <20231117130717.19875-1-yi.l.liu@intel.com>
 <20231117130717.19875-3-yi.l.liu@intel.com>
 <BN9PR11MB5276D8406BF08B853329288C8CB4A@BN9PR11MB5276.namprd11.prod.outlook.com>
 <fa736836-e136-4ed4-a6af-8ea2f0e7c0dd@intel.com>
 <BN9PR11MB527659462CCB7280055858D98CB4A@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZVuZOYFzAaCuJjXZ@Asurada-Nvidia>
 <BN9PR11MB5276C8EACE2C300A646EA8A18CBBA@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZVw/BXxgGCuCZCA6@Asurada-Nvidia>
 <BN9PR11MB52761A9B48A25E89BEECE6308CB8A@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZWTzoBTDDEWAKMs9@Asurada-Nvidia>
From:   Yi Liu <yi.l.liu@intel.com>
In-Reply-To: <ZWTzoBTDDEWAKMs9@Asurada-Nvidia>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SHNISWQwSXZHWjNtSy9KNGhJTzhvRGRoK0lUU04rVTdyc0pCdXp6ajBVb3ZH?=
 =?utf-8?B?SXM3VGhrZ1JpMjJNVHJaSERNeGRobW5qNk5MZ2drT3E0SDZxRlozTUFZRXhk?=
 =?utf-8?B?RlNUQkRkbFBUamxMVk42ckQzZ3RaanhJUG1NYzZUeXdEazdvOU1EaW93Y1dZ?=
 =?utf-8?B?UjA1ZkRoWmtyT09UTVoyT0VzKythZmJjd044b1NTOEcwN0tRYWdCSnNXNXll?=
 =?utf-8?B?S21yUStSdXdyR0ZEdlp1K244eXhnWHJZcC8rVVBVOTM1ZnJuTGt2ZWdZNVNJ?=
 =?utf-8?B?V294MmZ4TWYxZzJZWTkwcFd4ck9uc2JIMDZBNE1Lb1dGWXNMTjkySEQwRjVI?=
 =?utf-8?B?b0NrbTcyb3FMMUZadFR4SGJwWlBsTG43TlZKWEpjSnJmT1N1TUJsMHFuSkV2?=
 =?utf-8?B?TmJDQzlQU1BtYmcvYmVCb3Jad1h4QW9TQi8yN3I0UzMzSUtxWkZCTzdNRWFF?=
 =?utf-8?B?Zk9QcHZDRU02MTY5djh1WUJPMFoxWUQ5Mkp6WWZXTGJmUEpLcmZGMDZMNjNR?=
 =?utf-8?B?dmZVendYcFZsMFhaclMxRTVSQUY5RlB6MzdQc3NQV1p2K3YxZm04SHJsOHVx?=
 =?utf-8?B?Tm80R1A0ZVNEZTRWSTU3NzJTbWx1S2RzTzhmMEJOMnZ2TkhYSVpERjhuK0xT?=
 =?utf-8?B?a0R1NWtKdTRWeEdyVmI3QlR4THJEa3lrY2JoOGVvQ1hQa2tiVVZuSkF0RDZy?=
 =?utf-8?B?NnhDWUhuY0hYMjhSVGdaZ295dGI4MXZ0SWQ4N1owbDJNc3pFL2NMbEN4R3lZ?=
 =?utf-8?B?cGlyU3J1WjlOVXdPVmt0bnQyTlpNQm1iQ1JNZUJFVW1wMCtEZjVEMkJObDRt?=
 =?utf-8?B?SXhEaFB3WEdrdkpOQ3RlT0RoaTk4a3NkMzVLamZ3aXlPZXpEZUMvRGcvMzE1?=
 =?utf-8?B?aENiNXBUZyttSkJsTVhBc25RWWQ0c25CRFBiN2Y3WnhHZnJHdW9PU0NBdk1m?=
 =?utf-8?B?Y0l5TGthYThWcUVFYVJwdFhMUXJReVAzZTBVdTl4b3BCVmFhbGJya2RJNDh3?=
 =?utf-8?B?RCtRY2Qxb2xuY2Zsd250eE5CVmhSaGVWRlZ3b0ViOFI3Tm1kcjBBRkZPL1lI?=
 =?utf-8?B?TmV5aTIzZ3Z6WUVhQll2Sk1KYmtCTlVBVktack1LSE5lZWliY3o5d1JZRmov?=
 =?utf-8?B?NEhpajBSOVhKa3pJazRab3l6N3hlbVFhajRESVROQ1loeGd0ZXhrTXZvNlZv?=
 =?utf-8?B?Z09QMjRaNGVUSXl2NTg5c1FqQ3V4SWR0T1Fob0V2WG1SZk1JOEhuT2xWd3dv?=
 =?utf-8?B?YTlzQjFKdlJ0TFE1M3U4UE1CRkNmd3dzUlJMMGFpSHhCUXFTbEZ6SkROMU9l?=
 =?utf-8?B?SWRDbnNwbDhndGJKY0owcW1ybndaVlY3Vk1pbzRwNlVzakowWTRia1Y4Znho?=
 =?utf-8?B?THBibDRpR29PSE9NV1lRSE9mNFVGNFk5Nk1ZTkdFUm1GRTBQdTRvaGNXRFRX?=
 =?utf-8?B?WDBOem11Z3ptYUVHVjhXUDJMei9nQTZ4bUZyaXB1ZEN2UTdqUXcvZFJLNW5l?=
 =?utf-8?B?NlhqMGROK2wvZ29vYVhSR2YySDVrdXZuSkVFcEV5eFZHemp6Z2RQV2c3bFV1?=
 =?utf-8?B?V21ETzhhdnVRVi9aZTEyT3J6VFRjcXJtRGw0Q2NQdEVRMDRzbHJDTEtMcnVs?=
 =?utf-8?B?NWJYMm9USUxYQ1h2aklmSnVjK3p2SmpTejVFVm5KN0d4OTVGcEVnRFRTK2hZ?=
 =?utf-8?B?VzRVQ0g2VWgrNjRSTTlsV0EwYU0zQURNTVZtTzA2czVNTnVwNlo2eUIxZ1F3?=
 =?utf-8?B?dGkwODZ1VFphSzFCRENieWU3VGxUVVJaK0xiVXpMQ1k0d3ZrYkNjL0lrMlRl?=
 =?utf-8?B?NDRlbkNyblNaOTMxR0lDZjZwWTNra2VCL3VRYlpRaTNZU1dINXRkM05hZlE4?=
 =?utf-8?B?YmxsUUh3TWd4V3VlN2NyOWZtWFhseFpVR0MzT2ZNbzk2RzlCVk5kcm4vM3RK?=
 =?utf-8?B?OHNFell6cTBnQ3I1aUx3UEZ3NStrTWJVTDlqUTFIYVM1b3pETnJ2OTg2L0ZR?=
 =?utf-8?B?K2Q1bG9jZGZ0dkVtRks4bFhNc0VVcE1NWnpYdTRKdFlQcHFvWFNCN01ZWTBw?=
 =?utf-8?B?UmVMSVFmcmZqdXFWSW1HR09Ka0ZnRk5SY0JNRGhBMW1EaVptSUt4QWRZdzNm?=
 =?utf-8?Q?XDlHlBnTMsi2W+blMdeSvrV89?=
X-MS-Exchange-CrossTenant-Network-Message-Id: dd76264f-9e8a-43ed-27d0-08dbefd72ef6
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7529.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2023 05:59:29.6135
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8+2L7Bxe36m02TgiEy3gu02PIbj+gbvPUncD8KGHHhNaUhATmyHuUudcurh/KR8NhIvmsujqBVXc2i1KXeXyMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB6838
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 27 Nov 2023 21:59:43 -0800 (PST)

On 2023/11/28 03:53, Nicolin Chen wrote:
> On Fri, Nov 24, 2023 at 02:36:29AM +0000, Tian, Kevin wrote:
> 
>>>>>>>>> + * @out_driver_error_code: Report a driver speicifc error code
>>> upon
>>>>>>> failure.
>>>>>>>>> + *                         It's optional, driver has a choice to fill it or
>>>>>>>>> + *                         not.
>>>>>>>>
>>>>>>>> Being optional how does the user tell whether the code is filled or
>>> not?
>>>>>
>>>>> Well, naming it "error_code" indicates zero means no error while
>>>>> non-zero means something? An error return from this ioctl could
>>>>> also tell the user space to look up for this driver error code,
>>>>> if it ever cares.
>>>>
>>>> probably over-thinking but I'm not sure whether zero is guaranteed to
>>>> mean no error in all implementations...
>>>
>>> Well, you are right. Usually HW conveniently raises a flag in a
>>> register to indicate something wrong, yet it is probably unsafe
>>> to say it definitely.
>>>
>>
>> this reminds me one open. What about an implementation having
>> a hierarchical error code layout e.g. one main error register with
>> each bit representing an error category then multiple error code
>> registers each for one error category? In this case probably
>> a single out_driver_error_code cannot carry that raw information.
> 
> Hmm, good point.
> 
>> Instead the iommu driver may need to define a customized error
>> code convention in uapi header which is converted from the
>> raw error information.
>>
>>  From this angle should we simply say that the error code definition
>> must be included in the uapi header? If raw error information can
>> be carried by this field then this hw can simply say that the error
>> code format is same as the hw spec defines.
>>
>> With that explicit information then the viommu can easily tell
>> whether error code is filled or not based on its own convention.
> 
> That'd be to put this error_code field into the driver uAPI
> structure right?

looks to be. Then it would be convenient to reserve a code for
the case of no error (either no error happened or just not used)

> 
> I also thought about making this out_driver_error_code per HW.
> Yet, an error can be either per array or per entry/quest. The
> array-related error should be reported in the array structure
> that is a core uAPI, v.s. the per-HW entry structure. Though
> we could still report an array error in the entry structure
> at the first entry (or indexed by "array->entry_num")?

per-entry error code seems like to be a completion code. Each
entry in the array can have a corresponding code (0 for succ,
others for failure). do you already have such a need?

-- 
Regards,
Yi Liu