[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 2/4] xen/arm: Move make_hypervisor_node()
- To: Koichiro Den <den@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: "Orzel, Michal" <michal.orzel@xxxxxxx>
- Date: Mon, 23 Jun 2025 15:40:24 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ac2p6PoWZHUM3Ak080aYAAP/+ZaNy8jHvKiAwMtGhe0=; b=vY694uFDeoZgaQHC09EP4960GDtT2ttDN4RRQ/9hnVCDnnImrjW6F71A1J9ldmUSd2XmRAKMgJlDFOjJrPwJNnagNYHxA+o9M8WMgjWEKFRVC61KE3a5s3StlSOQ1TZuWQXbWA9ItbKl4ZOyAuwX6EueAr+lCziOK1iqento/CL3/YAi1wLonwhElLdKazaRRKcUWc2l+duPpVyb5U/E4UKzhGIJpoRAPt54agNSpuuPHc4UGs1TkZxgadZFUTYGdTZCaQiHtTeJr7YLsEKuLhHrVyvKEZ0MbGmphB0HSfkXdezk9/Tp7qrCnPX8Cpj9ZCvGUW9KR2V4MiCOGrD6lg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xTPCB+nYaFTGcrx2s5uYEVOnZ5sbp1/IWB8NzHdLNRV0b4EFS1Uf4EC7hitB17e0ftZbmQyzQXHmSOCljQSwPLugx+goDw+eAPdhCMGUalrzABKw/m/9UPzyRko3f+ldnJlqFgRlLELNSXSu88DU3Tq5LJN9cJCVH2SaHfJ8D5rqARyfBR6jzB9F+Vpo+pDEk9RCLgUHYTu1uC/tQenC1Fi+AHzf8htP0yafzmYx83ul3qQJELF753hJCpom5dp0WW5ER5/kDBw4QrEwizRBq7ltSlJ03CuQl3FKiFo6avTzshBkUrL0v4mATlKRWPno7+FvEp3bFhWFB19y2wBQpA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Mon, 23 Jun 2025 13:40:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 21/06/2025 17:11, Koichiro Den wrote:
> Even though make_hypervisor_node() does not rely on the /reserved-memory
> instantiation when calling find_unused_regions() (the wrapper introduced
> in the previous commit), the next but one commit will use it for PV time
Unless for specific reasons, you should not rely on which commit gets committed
first. Hypothetically there could be a different patch committed between this
and the next one in your series. That's why it's not a good practice to mention
order of commits in the commit message.
> shared regions, in addition to the existing extended regions.
>
> Move it as a prerequisite for the commit after next.
This one is particularly not useful.
>
> No functional changes intended.
>
> Signed-off-by: Koichiro Den <den@xxxxxxxxxxxxx>
Other than that, LGTM.
~Michal
|
