[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 5/5] xen/memory, tools: Make init-dom0less consume XEN_DOMCTL_get_mem_map


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Henry Wang <xin.wang2@xxxxxxx>
  • Date: Tue, 12 Mar 2024 11:44:13 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=HR421RGaH5R1i1LbuXUsNy0Y5fvdoCWT+n3WMAEeT/U=; b=h4udzrhZvIgP1TuYWSe+xtC34d8YsUC4MKDCz3asfno/gKye0oh+waMgjJ9XYlCZNJqDVF+1lR2Y1ueus/+VnZaRRnQQMffWh9tQQ2DibNWvr9G+OCzmYtvJiFJ3lxvN9xbAvv0YZYdGy5g9X7jqrcMtTfxEkkIDLrKP2MJcyvM6pBK8E/I3t8AIkKxmCR7C+rd7iViOwn++lNLPc14d6S4rE91r8gKbsbxigwlmYzQwwsjBc8b2Tnc8/aGxlTyeIt3TXK+xrQovakdWiN0A6fM0DZm7+PxhRiyR7TppBRbbU5N8VLg1faSvRv5JbcF6K9kfmeepb/TACD1h2fVP8Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=io5p5dGsc6auCqhRClgUlW1hoi3493HSHs5hHs3aMLaHJhQ/TtF1FUoUKYft0ta86UDEjsBDmaSp/N8Jjt0FsA/rdFpd4MNdmU2/cFuLxUDWNrQGibOqslI49D2cwffNFpiYabjH3kczTT+DNryvw7EU4kwm6z5EoANLe/kGJSMaimxgXFC8BgxYsPbE0RLo1G5X887mqzbtCHyzK510DpJVK1Qhbd4I+St6BBacLJir5oPj8DyL0mYDMEx18dW1XSxND3YhmXLC5fhXneCK03QyYooWx66ITkl2tPWWBIIfsmwGNq2mfxwy3ak9irXho0NtCV4cWS+397+Pc86SWA==
  • Cc: Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Alec Kwapis <alec.kwapis@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 12 Mar 2024 03:44:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Jan,

On 3/12/2024 1:07 AM, Jan Beulich wrote:
I'm afraid the title doesn't really say what the patch actually means
to achieve.

On 08.03.2024 02:54, Henry Wang wrote:
Previous commits enable the toolstack to get the domain memory map,
therefore instead of hardcoding the guest magic pages region, use
the XEN_DOMCTL_get_mem_map domctl to get the start address of the
guest magic pages region. Add the (XEN)MEMF_force_heap_alloc memory
flags to force populate_physmap() to allocate page from domheap
instead of using 1:1 or static allocated pages to map the magic pages.
A patch description wants to be (largely) self-contained. "Previous
commits" shouldn't be mentioned; recall that the sequence in which
patches go in is unknown to you up front. (In fact the terms "commit"
or "patch" should be avoided altogether when describing what a patch
does. The only valid use I can think of is when referring to commits
already in the tree, and then typically by quoting their hash and
title.)

Thanks for the detailed explanation. I will rewrite the title and part of the commit message in v3 to make it clear.

--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -41,6 +41,11 @@
  #define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request)
  /* Flag to indicate the node specified is virtual node */
  #define XENMEMF_vnode  (1<<18)
+/*
+ * Flag to force populate physmap to use pages from domheap instead of 1:1
+ * or static allocation.
+ */
+#define XENMEMF_force_heap_alloc  (1<<19)
  #endif
If this is for populate_physmap only, then other sub-ops need to reject
its use.

I have to admit I'm a little wary of allocating another flag here and ...

--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -205,6 +205,8 @@ struct npfec {
  #define  MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush)
  #define _MEMF_no_scrub    8
  #define  MEMF_no_scrub    (1U<<_MEMF_no_scrub)
+#define _MEMF_force_heap_alloc 9
+#define  MEMF_force_heap_alloc (1U<<_MEMF_force_heap_alloc)
  #define _MEMF_node        16
  #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
  #define  MEMF_node(n)     ((((n) + 1) & MEMF_node_mask) << _MEMF_node)
... here - we don't have that many left. Since other sub-ops aren't
intended to support this flag, did you consider adding another (perhaps
even arch-specific) sub-op instead?

Not really, I basically followed the discussion from [1] to implement this patch. However I understand your concern. Just want to make sure if I understand your suggestion correctly, by "adding another sub-op" you mean adding a sub-op similar as "XENMEM_populate_physmap" but only with executing the "else" part I want, so we can drop the use of these two added flags? Thanks!

[1] https://lore.kernel.org/xen-devel/3982ba47-6709-47e3-a9c2-e2d3b4a2d8e3@xxxxxxx/

Kind regards,
Henry

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.