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 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 21CA6C48BF6 for ; Thu, 7 Mar 2024 12:21:00 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1riCjY-000441-BL; Thu, 07 Mar 2024 07:20:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riCjW-00043Y-2x for qemu-devel@nongnu.org; Thu, 07 Mar 2024 07:20:22 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riCjU-0001jw-9E for qemu-devel@nongnu.org; Thu, 07 Mar 2024 07:20:21 -0500 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Tr7ZB3wPxz6K9GS; Thu, 7 Mar 2024 20:16:18 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id B52FA140D26; Thu, 7 Mar 2024 20:20:16 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 7 Mar 2024 12:20:16 +0000 Date: Thu, 7 Mar 2024 12:20:15 +0000 To: fan CC: , , , , , , , , , , , Fan Ni Subject: Re: [PATCH v5 08/13] hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release dynamic capacity response Message-ID: <20240307122015.00000b6a@Huawei.com> In-Reply-To: References: <20240304194331.1586191-1-nifan.cxl@gmail.com> <20240304194331.1586191-9-nifan.cxl@gmail.com> <20240306172827.000052dc@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500002.china.huawei.com (7.191.160.78) To lhrpeml500005.china.huawei.com (7.191.163.240) Received-SPF: pass client-ip=185.176.79.56; envelope-from=jonathan.cameron@huawei.com; helo=frasgout.his.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Jonathan Cameron From: Jonathan Cameron via Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Wed, 6 Mar 2024 13:39:50 -0800 fan wrote: > > > + } > > > + if (len2) { > > > + cxl_insert_extent_to_extent_list(extent_list, dpa + len, > > > + len2, NULL, 0); > > > + ct3d->dc.total_extent_count += 1; > > > + } > > > + break; > > Maybe this makes sense after the support below is added, but at this > > point in the series > > return CXL_MBOX_SUCCESS; > > then found isn't relevant so can drop that. Looks like you drop it later in the > > series anyway. > > We cannot return directly as we have more extents to release. Ah good point. I'd missed the double loop. > One thing I think I need to add is a dry run to test if any extent in > the income list is not contained by an extent in the extent list and > return error before starting to do the real release. The spec just says > we need to return invalid PA but not specify whether we should update the list > until we found a "bad" extent or reject the request directly. Current code > leaves a situation where we may have updated the extent list until we found a > "bad" extent to release. Yes, I'm not sure on the correct answer to this either. My assumption is that in error cases there are no side effects, but I don't see a clear statement of that. So I think we are in the world of best practice, not spec compliance. If we wanted to recover from such an error case we'd have to verify the current extent list. I'll fire off a question to relevant folk in appropriate forum. Jonathan