Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Message-ID: <4aca68f7-f2ea-76e8-c79c-ab4852e5cb50@intel.com>
Date:   Wed, 18 Oct 2023 14:12:16 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.13.0
Subject: Re: [PATCH v4 01/17] iommu: Add hwpt_type with user_data for
 domain_alloc_user op
Content-Language: en-US
To:     "Tian, Kevin" <kevin.tian@intel.com>,
        Nicolin Chen <nicolinc@nvidia.com>,
        Jason Gunthorpe <jgg@nvidia.com>
CC:     "joro@8bytes.org" <joro@8bytes.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.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>,
        "Martins, Joao" <joao.m.martins@oracle.com>
References: <20230921075138.124099-1-yi.l.liu@intel.com>
 <20230921075138.124099-2-yi.l.liu@intel.com>
 <20231010165844.GQ3952@nvidia.com>
 <03ba68e9-33ef-35c1-5720-8f559f94f8a1@intel.com>
 <20231012133917.GL3952@nvidia.com>
 <3659d9a7-d9e9-bb73-daf5-41c765e99c8c@intel.com>
 <20231013140456.GR3952@nvidia.com> <ZSmE6unIukqJ3GKu@Asurada-Nvidia>
 <79f0cab5-39ad-3d98-3896-6e1ba7b8db21@intel.com>
 <20231016115407.GO3952@nvidia.com> <ZS1+VMEo+0bCecui@Asurada-Nvidia>
 <2a86074f-94a9-667d-6e94-c582d49b7588@intel.com>
 <BN9PR11MB527671149ECD3DF3696A39988CD6A@BN9PR11MB5276.namprd11.prod.outlook.com>
From:   Yi Liu <yi.l.liu@intel.com>
In-Reply-To: <BN9PR11MB527671149ECD3DF3696A39988CD6A@BN9PR11MB5276.namprd11.prod.outlook.com>
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?dUh2Zm0zWHhhaHRnb1d6SVgzbUZ5WjkrNWN3VDk4blVWWmovZFRnV3U1T3k0?=
 =?utf-8?B?VFBFZlpMdUdBNXNSTEJkMm51czFQUEk5Y2huVHVaRzVRK0lLUFRYeHF0WWNr?=
 =?utf-8?B?QzE5emdLQ2FjQ0QrRXg2TE1XL1Z0YTd4UUpZUXEyVDNDTm05bitlV1RTeitT?=
 =?utf-8?B?d2pJd1dsTFArZ0VYNXBneE5NNVYrNzM5WkZ0NXBkbW5VV3FEcXBGL0xBY2t5?=
 =?utf-8?B?RFlRQ2t3U2lLRElmd294RFBrV1ZsNmpBOEZrRlkzUFIrNXZtUGdYZytycm1Y?=
 =?utf-8?B?c1ZBYUYyMitKR0JzdWFhUnd1Z3Q3UWlGQ0JENVl6YUVNaC9SaU1JVVN1RWlQ?=
 =?utf-8?B?T3lqRjZjZkk4dW5zU3RqbmtZcGpPRlNqRnRwRVRSbzN5S3ZiTlBRNE5zMVJ4?=
 =?utf-8?B?VDVoaGpGQ0p6TVZFbytqM1MzbFlMZGY0VUZzbE9oc0JkNWZmbXdTc2QvZ3E1?=
 =?utf-8?B?cEc3alVCZHdwTGNmYnorQmg4dk5wSXBQTEtsWVlPZENUZzExRHpVZ0pvMngx?=
 =?utf-8?B?Y3N2LzRPR3E1K0NNWm5ja29oY1YwWEFqdFB1dzAxenRyK3o0UktnakxzWFBT?=
 =?utf-8?B?NktMbGM2LzkvQjJmb2tyUkd2dURJcjI0eVFLbTR2UGpGMXRPbHlnaFNPOXUx?=
 =?utf-8?B?aUQwcTJGMEFXbTZSZjNJaUlEeFFTM0tjRlhlSU1iMncrN3FpenY3ai9NbUNx?=
 =?utf-8?B?b1AySk0xUEtaL3Zrejc2djl6TEFlTUFtbDd5d3BsRTJ3dkNxS3RJd3BqTGZx?=
 =?utf-8?B?cm5sZHJXT0lHYktlM3FXZzI0QWg4MCtNc2NWeS9YeEl1Y3JkbGxOZ1Y0MFhn?=
 =?utf-8?B?Q3R4MDRTYVY4V3NZSEVFQUhaRnYxRnF0N3BqRlVTSHBFMm1KRDR6T1VyYzZu?=
 =?utf-8?B?Uy9aVkttM1JidmRWbnlOWTRkVGNlRUExUzllZ01KZyt1Z280SDlBTUNYOHJs?=
 =?utf-8?B?UFY0eThsb3pzNlpmODRId3dTLzlqVnMzNExtczVwMUl4V2t0V1VoWXNCb2Nz?=
 =?utf-8?B?REZSOG4zR1ZhRDVDR1gwdjViMEdueWo0Q0tFSEdkNXBPd2Uzb3VEbWI1V1ZR?=
 =?utf-8?B?MGFqZ1hRWmZEaHNYNEthZGFzWi9taUI2eVNDQXA4SWNUNXZLMmhuNS9tQ2Rn?=
 =?utf-8?B?R2p0cm45UjkzQTFyMi9Zbk9hbnd4dEtEVWtsdEZZWlZYdTduK3lndFl5cnhI?=
 =?utf-8?B?WEtiWUZvbG9OTXRySEhCQlZaeTNhdGU0UG0zNXBYMWErbHhEMVZveHJZOEVy?=
 =?utf-8?B?T2l2b0oyU0llZVl2Ui85VkpkWHRNWDV6cDl2Z0FUbmNjY0hUZ0c2TnExWURI?=
 =?utf-8?B?WGJPSVZjMTVSRWkrTFQ3V2l3MjVhelBoQStpRzd1dEdHNlNldE9TdEdRNzBl?=
 =?utf-8?B?NDVzb0g5cElnb05EMVI5SVJxd2NzYjZqTXF6UDF1blhkVWxzNzRtczVzQkU5?=
 =?utf-8?B?TkFJTGl2MHR2RGhDeXpSdCtuWTM2Qkl0RDJzVVJRYm1pT1o0TGlLSmp2UUh5?=
 =?utf-8?B?aWpyRkIvVVFyVld4OW1MeTRLYVAwRnlUNEdjMnZzc1RhY1pMUVdscHhCbTVR?=
 =?utf-8?B?eVNJem5ZSjIxMVEwV2Nva3E0L2tkc3pyekhOeFpveHB6d0FQVzNoREZjVDRm?=
 =?utf-8?B?TE5HZlZXWlZsbW9GTmZWNGNrTkRLV3ZOa1A3cXFac01tK1hBYU41NXltZG9B?=
 =?utf-8?B?bk1ybkc3R1NRMTdSSnNxRW1PeUV2ZGlFbWl1RGM3MW45a1A3T0dsWU1vbXBC?=
 =?utf-8?B?Ynd6OHUwYThtQk1vcXFvUUVwY3dsQW5Sd0J3OFVEWDZZbTlLamtwVU1xS1BE?=
 =?utf-8?B?OVljdnJXTjd0cmNIS09vSWVMK1pHYmppWGVMV1l5eFFXY0VCZXhZdXFPbGhL?=
 =?utf-8?B?RnZUcGc1ZXJzUjFIK2RpUDJTYVd3Nk1EekJEeDM0VGx6OWpjM1lZUERES242?=
 =?utf-8?B?b1EvN2hCL0QxM0hlQlJXYXZPZEYyTy9HUURkVHM4OE1wQUtabDNMeFN1Nlli?=
 =?utf-8?B?M1ZXbC8zaUsxZ1AzcXJaWVRqQXE1MXAwbnhyU2tCRVJxNUFodFFIblRoLzhq?=
 =?utf-8?B?azRZNzY0UkVueTJrcC9hbE53dWZDNjMyZnVzQ2lBb0IzMXNNUFdpVHhaR0t3?=
 =?utf-8?Q?sZzL549uX/LUusCTYUX55EXs6?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 123cbd51-7305-419c-5b30-08dbcfa0d9dd
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7529.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2023 06:09:56.7886
 (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: nya+xIhoHiqXlUtkoHVEK8o292abrybPt+ucWj7mJR/hBy/Pdd0v6XlQyQMQw5o5iJLOEPNFMAxeCWt+50Umqg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5940
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.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 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 23:10:28 -0700 (PDT)

On 2023/10/17 17:28, Tian, Kevin wrote:
>> From: Liu, Yi L <yi.l.liu@intel.com>
>> Sent: Tuesday, October 17, 2023 4:52 PM
>>
>> On 2023/10/17 02:17, Nicolin Chen wrote:
>>> On Mon, Oct 16, 2023 at 08:54:07AM -0300, Jason Gunthorpe wrote:
>>>> On Mon, Oct 16, 2023 at 11:28:15AM +0800, Yi Liu wrote:
>>>>> On 2023/10/14 01:56, Nicolin Chen wrote:
>>>>>> On Fri, Oct 13, 2023 at 11:04:56AM -0300, Jason Gunthorpe wrote:
>>>>>>> On Fri, Oct 13, 2023 at 12:33:13PM +0800, Yi Liu wrote:
>>>>>>>
>>>>>>>> not really. Below the users of the struct iommu_user_data in my
>> current
>>>>>>>> iommufd_nesting branch. Only the domain_alloc_user op has type as
>> there
>>>>>>>> can be multiple vendor specific alloc data types. Basically, I'm ok to
>>>>>>>> make the change you suggested, just not sure if it is good to add type
>>>>>>>> as it is only needed by one path.
>>>>>>>
>>>>>>> I don't think we should ever have an opaque data blob without a type
>>>>>>> tag..
>>>>>>
>>>>>> I can add those "missing" data types, and then a driver will be
>>>>>> responsible for sanitizing the type along with the data_len.
>>>>>>
>>>>>> I notice that the enum iommu_hwpt_data_type in the posted patch
>>>>>> is confined to the alloc_user uAPI. Perhaps we should share it
>>>>>> with invalidate too:
>>>>>
>>>>> invalidation path does not need a type field today as the data
>>>>> type is vendor specific, vendor driver should know the data type
>>>>> when calls in.
>>>>
>>>> I'm not keen on that, what if a driver needs another type in the
>>>> future?  You'd want to make the invalidation data format part of the
>>>> domain allocation?
>>>
>>> The invalidation data has hwpt_id so it's tied to a hwpt and its
>>> hwpt->domain. Would it be reasonable to have a different type of
>>> invalidation data for the same type of hwpt?
>>
>> this seems like what Jason asks. A type of hwpt can have two kinds
>> of invalidation data types. Is it really possible?
>>
> 
> e.g. vhost-iommu may want its own vendor-agnostic format from
> previous discussion...

ok. So in future, if there is vendor-agnostic format cache invalidation
data structure, then each existing hwpt types would have two cache
invalidation types. is it?

So it is required to make the invalidation data format part of the
domain allocation. Perhaps we can add it later?

Regards,
Yi Liu

-- 
Regards,
Yi Liu