On 10/02/2017 05:37 PM, HW42 wrote: > Juergen Gross: >> When setting up the Xenstore watch for the memory target size the new >> watch will fire at once. Don't try to reach the configured target size >> by onlining new memory in this case, as the current memory size will >> be smaller in almost all cases due to e.g. BIOS reserved pages. >> >> Onlining new memory will lead to more problems e.g. undesired conflicts >> with NVMe devices meant to be operated as block devices. >> >> Instead remember the difference between target size and current size >> when the watch fires for the first time and apply it to any further >> size changes, too. >> >> In order to avoid races between balloon.c and xen-balloon.c init calls >> do the xen-balloon.c initialization from balloon.c. >> >> Signed-off-by: Juergen Gross <jgr...@suse.com> > This patch seems to introduce a regression. If I boot a HVM or PVH > domain with memory != maxmem then the kernel inside the domain reports > that it has maxmem available even though Xen reports only what is set as > memory. Sooner or later Xen logs "out of PoD memory!" and kills the > domain. If I revert the corresponding commit (96edd61d) then everything > works as expected. > > Tested this with Xen 4.9.0 and Linux 4.13.4. >
Yes, this indeed doesn't look like it's doing the right thing (although I haven't seen the "out of memory" error). I wonder whether target_diff should be computed against xenstore's "static-max" and not "target" and the memory should be ballooned down immediately and not on a subsequent watch firing. Unfortunately Juergen is out for a couple of weeks and I'd like to hear from him first since he is the one who wrote this patch. -boris
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
