xc_dom_alloc_segment() is passed a size in bytes, calculates a size in pages
from it, then fills in the new segment information with a bytes value
re-calculated from the number of pages.
This causes the module information given to the guest (MB, or PVH) to have
incorrect sizes; specifically, sizes rounded up to the next page.
This in turn is problematic for Xen. When Xen finds a gzipped module, it
peeks at the end metadata to judge the decompressed size, which is a -4
backreference from the reported end of the module.
Fill in seg->vend using the correct number of bytes.
Fixes: ea7c8a3d0e82 ("libxc: reorganize domain builder guest memory allocator")
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Anthony PERARD <anth...@xenproject.org>
CC: Juergen Gross <jgr...@suse.com>
CC: Oleksii Kurochko <oleksii.kuroc...@gmail.com>
For 4.19: This was discovered when trying to test Daniel's gzip cleanup for
Hyperlaunch. It's a subtle bug, hidden inside a second bug which isn't
appropriate content for 4.20.
---
tools/libs/guest/xg_dom_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
index c4f4e7f3e27a..f5521d528be1 100644
--- a/tools/libs/guest/xg_dom_core.c
+++ b/tools/libs/guest/xg_dom_core.c
@@ -601,7 +601,7 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
memset(ptr, 0, pages * page_size);
seg->vstart = start;
- seg->vend = dom->virt_alloc_end;
+ seg->vend = start + size;
DOMPRINTF("%-20s: %-12s : 0x%" PRIx64 " -> 0x%" PRIx64
" (pfn 0x%" PRIpfn " + 0x%" PRIpfn " pages)",
--
2.39.2
