Hi Jan,
On 4/19/2024 2:18 PM, Jan Beulich wrote:
On 19.04.2024 04:31, Henry Wang wrote:
On 4/18/2024 8:54 PM, Jan Beulich wrote:
On 09.04.2024 06:53, Henry Wang wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -21,6 +21,7 @@
#define XENMEM_increase_reservation 0
#define XENMEM_decrease_reservation 1
#define XENMEM_populate_physmap 6
+#define XENMEM_populate_physmap_heap_alloc 29
Without a comment, how is one supposed to know what the difference is of
this new sub-op compared to the "normal" one? I actually wonder whether
referring to a Xen internal (allocation requested to come from the heap)
is actually a good idea here. I'm inclined to suggest to name this after
the purpose it has from the guest or tool stack perspective.
Speaking of which: Is this supposed to be guest-accessible, or is it
intended for tool-stack use only (I have to admit I don't even know where
init-dom0less actually runs)? In the latter case that also wants enforcing.
This may require an adjustment to the XSM hook in use here. Cc-ing Daniel
for possible advice.
This sub-op should be called by the init-dom0less application (toolstack
side), which runs in Dom0.
I'm puzzled: How can init-dom0less (note its name!) run in Dom0, when there
is none?
[1] is the original patch that introduced this application (More details
can be found in the cover letter of the original series of [1]). I think
the use case for this application is to make dom0less domains to use the
PV driver when dom0 and dom0less domUs exist at the same time. There
used to be a discussion regarding the naming confusion, see [2] commit
message, but I cannot remember if this discussion has settled or not.
[1]
https://lore.kernel.org/xen-devel/20220505001656.395419-6-sstabell...@kernel.org/
[2]
https://lore.kernel.org/xen-devel/20230630091210.3742121-1-luca.fance...@arm.com/
Kind regards,
Henry
Jan
Daniel has proposed an alternative solution
which is based on the hypfs. If we decide to go that route, I think I
will rewrite the series. I will wait for the discussion settled. Thanks
for looping in Daniel!
Kind regards,
Henry
