RE: [RFC 2/2] Drivers: hv: balloon: Disable balloon and hot-add accordingly

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

 



From: Boqun Feng <boqun.feng@xxxxxxxxx> Sent: Wednesday, February 23, 2022 5:16 AM
> 
> Currently there are known potential issues for balloon and hot-add on
> ARM64:
> 
> *	Unballoon requests from Hyper-V should only unballoon ranges
> 	that are guest page size aligned, otherwise guests cannot handle
> 	because it's impossible to partially free a page.
> 
> *	Memory hot-add requests from Hyper-V should provide the NUMA
> 	node id of the added ranges or ARM64 should have a functional
> 	memory_add_physaddr_to_nid(), otherwise the node id is missing
> 	for add_memory().
> 
> These issues require discussions on design and implementation. In the
> meanwhile, post_status() is working and essiential to guest monitoring.
> Therefore instead of the entire hv_balloon driver, the balloon and
> hot-add are disabled accordingly for now. Once the issues are fixed,
> they can be re-enable in these cases.
> 
> Signed-off-by: Boqun Feng <boqun.feng@xxxxxxxxx>
> ---
>  drivers/hv/hv_balloon.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 062156b88a87..35dcda20be85 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1730,9 +1730,19 @@ static int balloon_connect_vsp(struct hv_device *dev)
>  	 * When hibernation (i.e. virtual ACPI S4 state) is enabled, the host
>  	 * currently still requires the bits to be set, so we have to add code
>  	 * to fail the host's hot-add and balloon up/down requests, if any.
> +	 *
> +	 * We disable balloon if the page size is larger than 4k, since
> +	 * currently it's unclear to us whether an unballoon request can make
> +	 * sure all page ranges are guest page size aligned.
> +	 *
> +	 * We also disable hot add on ARM64, because we currently rely on
> +	 * memory_add_physaddr_to_nid() to get a node id of a hot add range,
> +	 * however ARM64's memory_add_physaddr_to_nid() always return 0 and
> +	 * DM_MEM_HOT_ADD_REQUEST doesn't have the NUMA node information for
> +	 * add_memory().
>  	 */
> -	cap_msg.caps.cap_bits.balloon = 1;
> -	cap_msg.caps.cap_bits.hot_add = 1;
> +	cap_msg.caps.cap_bits.balloon = !(PAGE_SIZE > 4096UL);

Any reasons not to use HV_HYP_PAGE_SIZE vs. open coding "4096"?  So

	cap_msg.caps.cap_bits.balloon = (PAGE_SIZE == HV_HYP_PAGE_SIZE);

> +	cap_msg.caps.cap_bits.hot_add = !IS_ENABLED(CONFIG_ARM64);

I think we should output a message so that there's no mystery as to 
whether ballooning and/or hot_add are disabled, and why.  Each setting
should have its own message.   Maybe something like:

	if (!cap_msg.caps.cap_bits.balloon)
		pr_info("Ballooning disabled because page size is not 4096 bytes\n");

	if (!cap_msg.cap_bits.hot_add)
		pr_info("Memory hot add disabled on ARM64\n");

> 
>  	/*
>  	 * Specify our alignment requirements as it relates
> --
> 2.35.1





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux