[Xen-devel] [PATCH 1/2] xen: expand BALLOON_MEMORY_HOTPLUG description

[Xen-devel] [PATCH 1/2] xen: expand BALLOON_MEMORY_HOTPLUG description

[Roger Pau Monne]

To mention it's also useful for PVH or HVM domains that require
mapping foreign memory or grants.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
---
 drivers/xen/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 61212fc7f0c7..57ddd6f4b729 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -19,6 +19,10 @@ config XEN_BALLOON_MEMORY_HOTPLUG
 	  It is very useful on critical systems which require long
 	  run without rebooting.
 
+	  It's also very useful for translated domains (PVH or HVM) to obtain
+	  unpopulated physical memory ranges to use in order to map foreign
+	  memory or grants.
+
 	  Memory could be hotplugged in following steps:
 
 	    1) target domain: ensure that memory auto online policy is in
-- 
2.25.0

[Xen-devel] [PATCH 2/2] xen: enable BALLOON_MEMORY_HOTPLUG by default

[Roger Pau Monne]

Without it a PVH dom0 is mostly useless, as it would balloon down huge
amounts of RAM in order get physical address space to map foreign
memory and grants, ultimately leading to an out of memory situation.

Such option is also needed for HVM or PVH driver domains, since they
also require mapping grants into physical memory regions.

Suggested-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
---
 drivers/xen/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 57ddd6f4b729..c344bcffd89d 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -13,6 +13,7 @@ config XEN_BALLOON
 config XEN_BALLOON_MEMORY_HOTPLUG
 	bool "Memory hotplug support for Xen balloon driver"
 	depends on XEN_BALLOON && MEMORY_HOTPLUG
+	default y
 	help
 	  Memory hotplug support for Xen balloon driver allows expanding memory
 	  available for the system above limit declared at system startup.
-- 
2.25.0

Re: [Xen-devel] [PATCH 2/2] xen: enable BALLOON_MEMORY_HOTPLUG by default

[Jürgen Groß]

On 24.03.20 16:00, Roger Pau Monne wrote:
> Without it a PVH dom0 is mostly useless, as it would balloon down huge
> amounts of RAM in order get physical address space to map foreign
> memory and grants, ultimately leading to an out of memory situation.
> 
> Such option is also needed for HVM or PVH driver domains, since they
> also require mapping grants into physical memory regions.
> 
> Suggested-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org
> ---
>   drivers/xen/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 57ddd6f4b729..c344bcffd89d 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -13,6 +13,7 @@ config XEN_BALLOON
>   config XEN_BALLOON_MEMORY_HOTPLUG
>   	bool "Memory hotplug support for Xen balloon driver"
>   	depends on XEN_BALLOON && MEMORY_HOTPLUG
> +	default y
>   	help
>   	  Memory hotplug support for Xen balloon driver allows expanding memory
>   	  available for the system above limit declared at system startup.
> 

Another variant would be to set: default XEN_BACKEND

This would match the reasoning for switching it on.

Either way would be fine with me, so you can add

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

Re: [Xen-devel] [PATCH 2/2] xen: enable BALLOON_MEMORY_HOTPLUG by default

[Roger Pau Monné]

On Tue, Mar 24, 2020 at 04:09:35PM +0100, Jürgen Groß wrote:
> On 24.03.20 16:00, Roger Pau Monne wrote:
> > Without it a PVH dom0 is mostly useless, as it would balloon down huge
> > amounts of RAM in order get physical address space to map foreign
> > memory and grants, ultimately leading to an out of memory situation.
> > 
> > Such option is also needed for HVM or PVH driver domains, since they
> > also require mapping grants into physical memory regions.
> > 
> > Suggested-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > Cc: xen-devel@lists.xenproject.org
> > ---
> >   drivers/xen/Kconfig | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 57ddd6f4b729..c344bcffd89d 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -13,6 +13,7 @@ config XEN_BALLOON
> >   config XEN_BALLOON_MEMORY_HOTPLUG
> >   	bool "Memory hotplug support for Xen balloon driver"
> >   	depends on XEN_BALLOON && MEMORY_HOTPLUG
> > +	default y
> >   	help
> >   	  Memory hotplug support for Xen balloon driver allows expanding memory
> >   	  available for the system above limit declared at system startup.
> > 
> 
> Another variant would be to set: default XEN_BACKEND
> 
> This would match the reasoning for switching it on.

I would rather have it always on if possible, as gntdev or privcmd
(when used to map foreign pages from user-space) will also require it,
and they are not gated on XEN_BACKEND AFAICT.

> Either way would be fine with me, so you can add
> 
> Reviewed-by: Juergen Gross <jgross@suse.com>

Thanks!

Roger.

Re: [Xen-devel] [PATCH 2/2] xen: enable BALLOON_MEMORY_HOTPLUG by default

[Ian Jackson]

Roger Pau Monne writes ("Re: [PATCH 2/2] xen: enable BALLOON_MEMORY_HOTPLUG by default"):
> I would rather have it always on if possible, as gntdev or privcmd
> (when used to map foreign pages from user-space) will also require it,
> and they are not gated on XEN_BACKEND AFAICT.

Currently there seem to be problems with this:

http://logs.test-lab.xenproject.org/osstest/logs/149014/test-amd64-amd64-dom0pvh-xl-intel/info.html

For now I have rolled back the change in osstest to enable this option
explicitly.

Ian.

Re: [Xen-devel] [PATCH 1/2] xen: expand BALLOON_MEMORY_HOTPLUG description

[Jürgen Groß]

On 24.03.20 16:00, Roger Pau Monne wrote:
> To mention it's also useful for PVH or HVM domains that require
> mapping foreign memory or grants.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org
> ---
>   drivers/xen/Kconfig | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 61212fc7f0c7..57ddd6f4b729 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -19,6 +19,10 @@ config XEN_BALLOON_MEMORY_HOTPLUG
>   	  It is very useful on critical systems which require long
>   	  run without rebooting.
>   
> +	  It's also very useful for translated domains (PVH or HVM) to obtain

I'd rather say "(non PV)" or "(PVH, HVM or Arm)".

> +	  unpopulated physical memory ranges to use in order to map foreign
> +	  memory or grants.
> +
>   	  Memory could be hotplugged in following steps:
>   
>   	    1) target domain: ensure that memory auto online policy is in
> 

With that:

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

Re: [Xen-devel] [PATCH 1/2] xen: expand BALLOON_MEMORY_HOTPLUG description

[Roger Pau Monné]

On Tue, Mar 24, 2020 at 04:13:48PM +0100, Jürgen Groß wrote:
> On 24.03.20 16:00, Roger Pau Monne wrote:
> > To mention it's also useful for PVH or HVM domains that require
> > mapping foreign memory or grants.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > Cc: xen-devel@lists.xenproject.org
> > ---
> >   drivers/xen/Kconfig | 4 ++++
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 61212fc7f0c7..57ddd6f4b729 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -19,6 +19,10 @@ config XEN_BALLOON_MEMORY_HOTPLUG
> >   	  It is very useful on critical systems which require long
> >   	  run without rebooting.
> > +	  It's also very useful for translated domains (PVH or HVM) to obtain
> 
> I'd rather say "(non PV)" or "(PVH, HVM or Arm)".

I'm fine with any of the variants. Would you mind adjusting when
picking it up or would you like me to resend?

> > +	  unpopulated physical memory ranges to use in order to map foreign
> > +	  memory or grants.
> > +
> >   	  Memory could be hotplugged in following steps:
> >   	    1) target domain: ensure that memory auto online policy is in
> > 
> 
> With that:
> 
> Reviewed-by: Juergen Gross <jgross@suse.com>

Thanks!

Re: [Xen-devel] [PATCH 1/2] xen: expand BALLOON_MEMORY_HOTPLUG description

[Jürgen Groß]

On 24.03.20 16:18, Roger Pau Monné wrote:
> On Tue, Mar 24, 2020 at 04:13:48PM +0100, Jürgen Groß wrote:
>> On 24.03.20 16:00, Roger Pau Monne wrote:
>>> To mention it's also useful for PVH or HVM domains that require
>>> mapping foreign memory or grants.
>>>
>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>> ---
>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>> Cc: xen-devel@lists.xenproject.org
>>> ---
>>>    drivers/xen/Kconfig | 4 ++++
>>>    1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
>>> index 61212fc7f0c7..57ddd6f4b729 100644
>>> --- a/drivers/xen/Kconfig
>>> +++ b/drivers/xen/Kconfig
>>> @@ -19,6 +19,10 @@ config XEN_BALLOON_MEMORY_HOTPLUG
>>>    	  It is very useful on critical systems which require long
>>>    	  run without rebooting.
>>> +	  It's also very useful for translated domains (PVH or HVM) to obtain
>>
>> I'd rather say "(non PV)" or "(PVH, HVM or Arm)".
> 
> I'm fine with any of the variants. Would you mind adjusting when
> picking it up or would you like me to resend?

No need to resend. I'll use the "non PV" variant.


Juergen