A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
The first patch introduces XEN_PVHVM_GUEST as a toplevel item and
changes XEN_PVHVM to a hidden variable. This allows XEN_PVH to depend
on XEN_PVHVM without PCI while XEN_PVHVM_GUEST depends on PCI.
The second patch moves XEN_512GB to clean up the option nesting.
Jason Andryuk (2):
xen: Remove Xen PVH/PVHVM dependency on PCI
xen: Kconfig: nest Xen guest options
arch/x86/xen/Kconfig | 38 ++++++++++++++++++++++----------------
drivers/xen/Makefile | 2 +-
2 files changed, 23 insertions(+), 17 deletions(-)
--
2.26.2
A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
Introduce XEN_PVHVM_GUEST as a toplevel item and change XEN_PVHVM to a
hidden variable. This allows XEN_PVH to depend on XEN_PVHVM without PCI
while XEN_PVHVM_GUEST depends on PCI.
In drivers/xen, compile platform-pci depending on XEN_PVHVM_GUEST since
that pulls in the PCI dependency for linking.
Signed-off-by: Jason Andryuk <[email protected]>
---
---
arch/x86/xen/Kconfig | 18 ++++++++++++------
drivers/xen/Makefile | 2 +-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 218acbd5c7a0..b75007eb4ec4 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -39,16 +39,20 @@ config XEN_DOM0
Support running as a Xen PV Dom0 guest.
config XEN_PVHVM
- bool "Xen PVHVM guest support"
- default y
- depends on XEN && PCI && X86_LOCAL_APIC
- help
- Support running as a Xen PVHVM guest.
+ def_bool y
+ depends on XEN && X86_LOCAL_APIC
config XEN_PVHVM_SMP
def_bool y
depends on XEN_PVHVM && SMP
+config XEN_PVHVM_GUEST
+ bool "Xen PVHVM guest support"
+ default y
+ depends on XEN_PVHVM && PCI
+ help
+ Support running as a Xen PVHVM guest.
+
config XEN_512GB
bool "Limit Xen pv-domain memory to 512GB"
depends on XEN_PV
@@ -76,7 +80,9 @@ config XEN_DEBUG_FS
Enabling this option may incur a significant performance overhead.
config XEN_PVH
- bool "Support for running as a Xen PVH guest"
+ bool "Xen PVH guest support"
depends on XEN && XEN_PVHVM && ACPI
select PVH
def_bool n
+ help
+ Support for running as a Xen PVH guest.
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index babdca808861..c3621b9f4012 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_XEN_GNTDEV) += xen-gntdev.o
obj-$(CONFIG_XEN_GRANT_DEV_ALLOC) += xen-gntalloc.o
obj-$(CONFIG_XENFS) += xenfs/
obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o
-obj-$(CONFIG_XEN_PVHVM) += platform-pci.o
+obj-$(CONFIG_XEN_PVHVM_GUEST) += platform-pci.o
obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o
obj-$(CONFIG_XEN_MCE_LOG) += mcelog.o
obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/
--
2.26.2
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 <[email protected]>
---
arch/x86/xen/Kconfig | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
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
--
2.26.2
On 14.10.2020 19:53, Jason Andryuk wrote:
> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>
> config XEN_PVH
> - bool "Support for running as a Xen PVH guest"
> + bool "Xen PVH guest support"
Tangential question: Is "guest" here still appropriate, i.e.
isn't this option also controlling whether the kernel can be
used in a PVH Dom0?
> def_bool n
And is this default still appropriate?
Jan
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 <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
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 10/15/20 9:10 AM, Andrew Cooper wrote:
> On 15/10/2020 13:37, [email protected] 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 5:42 AM Jürgen Groß <[email protected]> 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 <[email protected]>
>
> Reviewed-by: Juergen Gross <[email protected]>
Thanks,
Jason
On Thu, Oct 15, 2020 at 9:17 AM <[email protected]> wrote:
>
>
> On 10/15/20 9:10 AM, Andrew Cooper wrote:
> > On 15/10/2020 13:37, [email protected] 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 4:10 AM Jan Beulich <[email protected]> wrote:
>
> On 14.10.2020 19:53, Jason Andryuk wrote:
> > @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> > Enabling this option may incur a significant performance overhead.
> >
> > config XEN_PVH
> > - bool "Support for running as a Xen PVH guest"
> > + bool "Xen PVH guest support"
>
> Tangential question: Is "guest" here still appropriate, i.e.
> isn't this option also controlling whether the kernel can be
> used in a PVH Dom0?
Would you like something more generic like "Xen PVH support" and
"Support for running in Xen PVH mode"?
> > def_bool n
>
> And is this default still appropriate?
We probably want to flip it on, yes. PVH is the future, isn't it?
Regards,
Jason
On 15.10.2020 16:59, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich <[email protected]> wrote:
>>
>> On 14.10.2020 19:53, Jason Andryuk wrote:
>>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
>>> Enabling this option may incur a significant performance overhead.
>>>
>>> config XEN_PVH
>>> - bool "Support for running as a Xen PVH guest"
>>> + bool "Xen PVH guest support"
>>
>> Tangential question: Is "guest" here still appropriate, i.e.
>> isn't this option also controlling whether the kernel can be
>> used in a PVH Dom0?
>
> Would you like something more generic like "Xen PVH support" and
> "Support for running in Xen PVH mode"?
Yeah, just dropping "guest" would be fine with me. No idea how
to reflect that PVH Dom0 isn't supported, yet.
Jan