Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <79089dc4-07c4-369b-826c-1c6e12edcaff@oracle.com>
Date:   Sat, 21 May 2022 03:13:23 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [PATCH 1/4] vdpa: Add stop operation
Content-Language: en-US
To:     =?UTF-8?Q?Eugenio_P=c3=a9rez?= <eperezma@redhat.com>,
        virtualization@lists.linux-foundation.org,
        Jason Wang <jasowang@redhat.com>, kvm@vger.kernel.org,
        "Michael S. Tsirkin" <mst@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Cc:     Stefano Garzarella <sgarzare@redhat.com>,
        Longpeng <longpeng2@huawei.com>,
        Zhu Lingshan <lingshan.zhu@intel.com>, martinh@xilinx.com,
        hanand@xilinx.com, dinang@xilinx.com, Eli Cohen <elic@nvidia.com>,
        lvivier@redhat.com, pabloc@xilinx.com, gautam.dawar@amd.com,
        Xie Yongji <xieyongji@bytedance.com>, habetsm.xilinx@gmail.com,
        Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        tanuj.kamde@amd.com, Wu Zongyong <wuzongyong@linux.alibaba.com>,
        martinpo@xilinx.com, lulu@redhat.com, ecree.xilinx@gmail.com,
        Parav Pandit <parav@nvidia.com>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Zhang Min <zhang.min9@zte.com.cn>
References: <20220520172325.980884-1-eperezma@redhat.com>
 <20220520172325.980884-2-eperezma@redhat.com>
From:   Si-Wei Liu <si-wei.liu@oracle.com>
Organization: Oracle Corporation
In-Reply-To: <20220520172325.980884-2-eperezma@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T1E4SU1iOERGNHVVcmgxV3cxNWYxVXQzTjBJZ1ptOXZ6bHJnOWozRERqb0hP?=
 =?utf-8?B?YmIrZUtoK0E0V3cwZGw0dlJjZWtXV2VqUW1pOUcxcjhETVZZT1B3ZmpCL2Yw?=
 =?utf-8?B?UDB2TlcwM1ovbWQzbjduYm5vdzVFTHVDQ1laUm1hRHlUUVFIVEQxVDgvZTBM?=
 =?utf-8?B?enVnRXluZW9IcFFuMEI3NmVtcmw5alpNeUM4VFFUY2xlb2gxbEprQ3FaYlFv?=
 =?utf-8?B?RmQ5NTdqWUplQWg4NFYxR1VqdmpFQW9KV2NuaFVreThmYUtkczFlUHdha0Rs?=
 =?utf-8?B?cGtTVVFldUZuenFMOFgwZVREcGFxVURuY2lJaE1OV2huRStJTEdlVVc4eXJv?=
 =?utf-8?B?RVRrUGZOV3FOZ1hzdWFZdTdHMGZSRWZiSjdtQ0FCZ2p2bk1MTnYwVUg4b29a?=
 =?utf-8?B?NStMWkN1ZmZnZ2tnUldPZ0xjVVEzcFZKMWkxOTRhemVuTm5nb1lSaEhhejFv?=
 =?utf-8?B?ODNxYXI3MmJETWo4dmV5NkFFR21HcTdNMmhSbW1Qb1FxeDU1VGpRMmFhcG9B?=
 =?utf-8?B?Z1VMMTA4eTBqT1Y4WWV6SkpRa05VWXpNZjN3SDRBZzBWcXV1bzNGRmdPSkxY?=
 =?utf-8?B?OFZpYmJIc09jSnYzZmQ3TDBjM1JoVFFLSmVyek85d1VaYUsyN0xtUDJFMzZp?=
 =?utf-8?B?QmlrbDJyMlp2THVxcERBTDZMMmN1REZmeUZDaERNanlnNS9saFp1cHd5czAy?=
 =?utf-8?B?MHVxNHhHNUlrTW9kdzVNQjJQUUhyTklZQWlmWjc2REloQWZySUI1aDBRSll3?=
 =?utf-8?B?R09uMkZBQXZMS0tlc3lSM2ovdnZpVmhCbXM4U1ZCV25zTTJRV3VyNVVhYWk3?=
 =?utf-8?B?OUovQUpwd2pHZ2NEcFluNGVXS0t1M2lXbHVTYVZqU0tJS0VrcURibUE1SEFP?=
 =?utf-8?B?TEVGbEUwL0hiVUQwc0dQUTlEY0tqSEFmbjZHV1EvRDdRVGc3cmc4TGRiK2I4?=
 =?utf-8?B?Z1pTN0JHcnR0UktOWHljNXRjWktaZnVvMmZoZFdVVldmai9lbWVIS2M1WTlz?=
 =?utf-8?B?U3VNeWRhd3BxS0ZkUjlET1M2UEdUTzBJcjd6K0luUmo5eTVQeHMxS0xDWlMz?=
 =?utf-8?B?Z01YWjE0RTEwU28zTmNKeTJWcFYxdyt0OHl5a3ZxZ1Jwb2NVRnZhTm5xamo0?=
 =?utf-8?B?bWR4R2xHZkRxdmpYLzUwV25WanhmZ3lCVDBKa0t5WUN5Z3BpRG1XbVZPTGQ2?=
 =?utf-8?B?OU5QUldlWXAzOW1lNDFiK3h5WkVmbjhIMm02OHhMeFZ1NzNicGtjV29JdEI1?=
 =?utf-8?B?RWNhdSsrZk9KY2pLak1DUVBuN1EvcUVhZXMxZHFnanZocDFCUlg4TXB5K3NO?=
 =?utf-8?B?NUJZQ0JzYmZOV0U0cGxZTC9BajBSZDlNTW1NVDhGczduSUI4UzBzVldXb3Aw?=
 =?utf-8?B?d09GY2MzbzkxNHhDaTNPbk1FSzRERWgvcWJUOXI1VUsxN1NMdFcxcVRGRHV1?=
 =?utf-8?B?bjdJT1lDTlc4TFhjcDR4T2dKZDIyTTFRMTBMa0pERDNtaUp2N3NRcVVsa2VD?=
 =?utf-8?B?TDZ3cTdsNFMrblpKaXlRcWRxQlVHWk9Bb25ydFBCUWNWTjVxYU96cVYzSTlQ?=
 =?utf-8?B?MFFOcGdZK1JJZlVGMVJIQkhsQjFhQitwenkvUnI1RnYwK0dlc0R4VmlNcHAx?=
 =?utf-8?B?M2ZWYlB0Sml1WGlQVWhSbzY5OEZla0l0OUJEcTR1bzJwS0EzZklDbXNaWWtu?=
 =?utf-8?B?cnZVdTBuNDNvWnEyMTRTWFh1U0ViR2VuZkJtVDRjZ1J2ZVBIQ2M5TklQRTAx?=
 =?utf-8?B?RlFsbVJhN1Y2NmcwR3lpeUk1dGhGTjBKU042MVFLZlVYYjhUR2ZUcmdmWkhM?=
 =?utf-8?B?TnJBYWh2blZ4d2orSitkVVdkdkxWenJ0OFYydkpZUTk0ZE90T0NQZDB2VlB5?=
 =?utf-8?B?WlJUdk91QWNYaGM2bkpOcVdWbHk5NFlUUWxsdDltWWNYR1UwcmpyRm1KWkVO?=
 =?utf-8?B?Y1Bjc3FweGpBSG1ybmM5RE5XK3dMM3RBam15NktMaEw5eDV0Ymw1TmNIY3lJ?=
 =?utf-8?B?ajJhWDNlamZRTnU2TzJJYUF5VG9Xd2pZTnd3NjByMWEvVUZYcTV5YTY5dmtW?=
 =?utf-8?B?ZlI2VG5kQXhoTWx4SSt3ZUN0TWZrSHlSaUxSN3Y4OUVVSU9SeXNVV1dSSDlw?=
 =?utf-8?B?SEo1TnRYQ2NXWm1PUXdEbUMyMFlmcnRINUJDR0thdjJiZm9RbmN5S0RiazhJ?=
 =?utf-8?B?QVkxZ3RKQmZzM3l4K1g4bnVGbUMxVzUxa0VIcnZ2UlFERmNCUmxGUVZqMmZr?=
 =?utf-8?B?c053SlRrT2RUZUhsNUNFZVZPKzBKdkh4dkEyS2ZXUWZTb3Y2YjJSOFFxbVB5?=
 =?utf-8?B?ZkFHNkJyWHl3R1c5TFh5QTBhTTVXbGdGd0FMeHdvQ1lCRmJGdVBVUT09?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f667cfc5-1270-468c-f51d-08da3b128adb
X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3287.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2022 10:13:25.3967
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 69YWO+q2+LHqSQd0Tsw2C0fZq1KtOnRIHVgP1VLmQTvsq08ebJahTxpkFm/U4i1zJQTkohzhypi3U/cZsW9cIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB4896
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-21_03:2022-05-20,2022-05-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 malwarescore=0 spamscore=0 suspectscore=0 bulkscore=0 phishscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2205210062
X-Proofpoint-ORIG-GUID: 3ZK2lHW8acN80MO4fd1kTSD_GSOYxkrG
X-Proofpoint-GUID: 3ZK2lHW8acN80MO4fd1kTSD_GSOYxkrG
X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 5/20/2022 10:23 AM, Eugenio Pérez wrote:
> This operation is optional: It it's not implemented, backend feature bit
> will not be exposed.
>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> ---
>   include/linux/vdpa.h | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 15af802d41c4..ddfebc4e1e01 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -215,6 +215,11 @@ struct vdpa_map_file {
>    * @reset:			Reset device
>    *				@vdev: vdpa device
>    *				Returns integer: success (0) or error (< 0)
> + * @stop:			Stop or resume the device (optional, but it must
> + *				be implemented if require device stop)
> + *				@vdev: vdpa device
> + *				@stop: stop (true), not stop (false)
> + *				Returns integer: success (0) or error (< 0)
Is this uAPI meant to address all use cases described in the full blown 
_F_STOP virtio spec proposal, such as:

--------------%<--------------

...... the device MUST finish any in flight
operations after the driver writes STOP.  Depending on the device, it 
can do it
in many ways as long as the driver can recover its normal operation if it
resumes the device without the need of resetting it:

- Drain and wait for the completion of all pending requests until a
   convenient avail descriptor. Ignore any other posterior descriptor.
- Return a device-specific failure for these descriptors, so the driver
   can choose to retry or to cancel them.
- Mark them as done even if they are not, if the kind of device can
   assume to lose them.
--------------%<--------------

E.g. do I assume correctly all in flight requests are flushed after 
return from this uAPI call? Or some of pending requests may be subject 
to loss or failure? How does the caller/user specify these various 
options (if there are) for device stop?

BTW, it would be nice to add the corresponding support to vdpa_sim_blk 
as well to demo the stop handling. To just show it on vdpa-sim-net IMHO 
is perhaps not so convincing.

-Siwei

>    * @get_config_size:		Get the size of the configuration space includes
>    *				fields that are conditional on feature bits.
>    *				@vdev: vdpa device
> @@ -316,6 +321,7 @@ struct vdpa_config_ops {
>   	u8 (*get_status)(struct vdpa_device *vdev);
>   	void (*set_status)(struct vdpa_device *vdev, u8 status);
>   	int (*reset)(struct vdpa_device *vdev);
> +	int (*stop)(struct vdpa_device *vdev, bool stop);
>   	size_t (*get_config_size)(struct vdpa_device *vdev);
>   	void (*get_config)(struct vdpa_device *vdev, unsigned int offset,
>   			   void *buf, unsigned int len);