| Message ID | 20201014175342.152712-3-jandryuk@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | bfda93aee0ec95545d58be06ec1166f6c253995a |
| Headers | show |
| Series | Remove Xen PVH dependency on PCI | expand |
On 14.10.20 19:53, Jason Andryuk wrote: > Moving XEN_512GB allows it to nest under XEN_PV. That also allows > XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving: > > [*] Xen guest support > [*] Xen PV guest support > [*] Limit Xen pv-domain memory to 512GB > [*] Xen PV Dom0 support This has currently a wrong text/semantics: It should be split to CONFIG_XEN_DOM0 and CONFIG_XEN_PV_DOM0. Otherwise the backends won't be enabled per default for a PVH-only config meant to be Dom0-capable. You don't have to do that in your patches if you don't want to, but I wanted to mention it with you touching this area of Kconfig. > [*] Xen PVHVM guest support > [*] Xen PVH guest support > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Juergen
On 10/14/20 1:53 PM, Jason Andryuk wrote: > +config XEN_512GB > + bool "Limit Xen pv-domain memory to 512GB" > + depends on XEN_PV && X86_64 Why is X86_64 needed here? -boris
On 15/10/2020 13:37, boris.ostrovsky@oracle.com wrote: > On 10/14/20 1:53 PM, Jason Andryuk wrote: >> +config XEN_512GB >> + bool "Limit Xen pv-domain memory to 512GB" >> + depends on XEN_PV && X86_64 > > Why is X86_64 needed here? >512G support was implemented using a direct-mapped P2M, and is rather beyond the virtual address capabilities of 32bit. ~Andrew
On 10/15/20 9:10 AM, Andrew Cooper wrote: > On 15/10/2020 13:37, boris.ostrovsky@oracle.com wrote: >> On 10/14/20 1:53 PM, Jason Andryuk wrote: >>> +config XEN_512GB >>> + bool "Limit Xen pv-domain memory to 512GB" >>> + depends on XEN_PV && X86_64 >> Why is X86_64 needed here? >> 512G support was implemented using a direct-mapped P2M, and is rather > beyond the virtual address capabilities of 32bit. > Yes, my point was that XEN_PV already depends on X86_64. -boris
On Thu, Oct 15, 2020 at 9:17 AM <boris.ostrovsky@oracle.com> wrote: > > > On 10/15/20 9:10 AM, Andrew Cooper wrote: > > On 15/10/2020 13:37, boris.ostrovsky@oracle.com wrote: > >> On 10/14/20 1:53 PM, Jason Andryuk wrote: > >>> +config XEN_512GB > >>> + bool "Limit Xen pv-domain memory to 512GB" > >>> + depends on XEN_PV && X86_64 > >> Why is X86_64 needed here? > >> 512G support was implemented using a direct-mapped P2M, and is rather > > beyond the virtual address capabilities of 32bit. > > > > Yes, my point was that XEN_PV already depends on X86_64. Oh, thanks for catching this. I re-introduced it by accident when rebasing the patches. Regards, Jason
On Thu, Oct 15, 2020 at 5:42 AM Jürgen Groß <jgross@suse.com> wrote: > > On 14.10.20 19:53, Jason Andryuk wrote: > > Moving XEN_512GB allows it to nest under XEN_PV. That also allows > > XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving: > > > > [*] Xen guest support > > [*] Xen PV guest support > > [*] Limit Xen pv-domain memory to 512GB > > [*] Xen PV Dom0 support > > This has currently a wrong text/semantics: > > It should be split to CONFIG_XEN_DOM0 and CONFIG_XEN_PV_DOM0. > > Otherwise the backends won't be enabled per default for a PVH-only > config meant to be Dom0-capable. > > You don't have to do that in your patches if you don't want to, but > I wanted to mention it with you touching this area of Kconfig. Yes, good point. I had not considered that. > > [*] Xen PVHVM guest support > > [*] Xen PVH guest support > > > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > > Reviewed-by: Juergen Gross <jgross@suse.com> Thanks, Jason
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index b75007eb4ec4..2b105888927c 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -26,6 +26,19 @@ config XEN_PV help Support running as a Xen PV guest. +config XEN_512GB + bool "Limit Xen pv-domain memory to 512GB" + depends on XEN_PV && X86_64 + default y + help + Limit paravirtualized user domains to 512GB of RAM. + + The Xen tools and crash dump analysis tools might not support + pv-domains with more than 512 GB of RAM. This option controls the + default setting of the kernel to use only up to 512 GB or more. + It is always possible to change the default via specifying the + boot parameter "xen_512gb_limit". + config XEN_PV_SMP def_bool y depends on XEN_PV && SMP @@ -53,19 +66,6 @@ config XEN_PVHVM_GUEST help Support running as a Xen PVHVM guest. -config XEN_512GB - bool "Limit Xen pv-domain memory to 512GB" - depends on XEN_PV - default y - help - Limit paravirtualized user domains to 512GB of RAM. - - The Xen tools and crash dump analysis tools might not support - pv-domains with more than 512 GB of RAM. This option controls the - default setting of the kernel to use only up to 512 GB or more. - It is always possible to change the default via specifying the - boot parameter "xen_512gb_limit". - config XEN_SAVE_RESTORE bool depends on XEN
Moving XEN_512GB allows it to nest under XEN_PV. That also allows XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving: [*] Xen guest support [*] Xen PV guest support [*] Limit Xen pv-domain memory to 512GB [*] Xen PV Dom0 support [*] Xen PVHVM guest support [*] Xen PVH guest support Signed-off-by: Jason Andryuk <jandryuk@gmail.com> --- arch/x86/xen/Kconfig | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-)