* Drop one piece of trailing whitespace
* Reposition LATE_HWDOM so it sits properly nested inside XSM in menuconfig
* Spelling and grammar corrections
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: Jan Beulich
---
xen/common/Kconfig | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b2d3d61..92d4610 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -54,26 +54,6 @@ config KEXEC
If unsure, say Y.
-config LATE_HWDOM
- bool "dedicated hardware domain"
- default n
- depends on XSM && X86
- ---help---
- Allows the creation of a dedicated hardware domain distinct from
- domain 0 that manages devices without needing access to other
- privileged functionality such as the ability to manage domains.
- This requires that the actual domain 0 be a stub domain that
- constructs the actual hardware domain instead of initializing the
- hardware itself. Because the hardware domain needs access to
- hypercalls not available to unprivileged guests, an XSM policy
- is required to properly define the privilege of these domains.
-
- This feature does nothing if the "hardware_dom" boot parameter is
- not present. If this feature is being used for security, it should
- be combined with an IOMMU in strict mode.
-
- If unsure, say N.
-
config TMEM
def_bool y
prompt "Transcendent Memory Support" if EXPERT = "y"
@@ -141,7 +121,7 @@ config XSM_POLICY
depends on XSM
---help---
This includes a default XSM policy in the hypervisor so that the
- bootloader does not need to load a policy to get sane behavior from an
+ bootloader does not need to load a policy to get sane behaviour from
an
XSM-enabled hypervisor. If this is disabled, a policy must be
provided by the bootloader or by Domain 0. Even if this is enabled, a
policy provided by the bootloader will override it.
@@ -151,6 +131,26 @@ config XSM_POLICY
If unsure, say Y.
+config LATE_HWDOM
+ bool "Dedicated hardware domain"
+ default n
+ depends on XSM && X86
+ ---help---
+ Allows the creation of a dedicated hardware domain distinct from
+ domain 0 that manages devices without needing access to other
+ privileged functionality such as the ability to manage domains.
+ This requires that the actual domain 0 be a stub domain that
+ constructs the actual hardware domain instead of initializing the
+ hardware itself. Because the hardware domain needs access to
+ hypercalls not available to unprivileged guests, an XSM policy
+ is required to properly define the privilege of these domains.
+
+ This feature does nothing if the "hardware_dom" boot parameter is
+ not present. If this feature is being used for security, it should
+ be combined with an IOMMU in strict mode.
+
+ If unsure, say N.
+
menu "Schedulers"
visible if EXPERT = "y"
@@ -183,7 +183,7 @@ config SCHED_ARINC653
choice
prompt "Default Scheduler?"
- default SCHED_CREDIT_DEFAULT
+ default SCHED_CREDIT_DEFAULT
config SCHED_CREDIT_DEFAULT
bool "Credit Scheduler" if SCHED_CREDIT
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
