docs/cmdline: Move XSM to be in alphabetical order

Adjust the default line to note that the default is now selectable in Kconfig.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This commit is contained in:
Andrew Cooper committed 2018-12-10 15:55:01 +00:00
1 parent 5e4af078e8
commit 3fdb28e3bc
1 file changed
+16 -16
+16 -16
View File
@@ -870,22 +870,6 @@ hardware domain is architecture dependent.
Note that specifying zero as domU value means zero, while for dom0 it means
to use the default.
### xsm
> `= dummy | flask | silo`
> Default: `dummy`
Specify which XSM module should be enabled. This option is only available if
the hypervisor was compiled with XSM support.
* `dummy`: this is the default choice. Basic restriction for common deployment
(the dummy module) will be applied. It's also used when XSM is compiled out.
* `flask`: this is the policy based access control. To choose this, the
separated option in kconfig must also be enabled.
* `silo`: this will deny any unmediated communication channels between
unprivileged VMs. To choose this, the separated option in kconfig must also
be enabled.
### flask
> `= permissive | enforcing | late | disabled`
@@ -2180,3 +2164,19 @@ for dom0 or guest domains only.
> Default: `true`
Permit use of the `xsave/xrstor` instructions.
### xsm
> `= dummy | flask | silo`
> Default: selectable via Kconfig. Depends on enabled XSM modules.
Specify which XSM module should be enabled. This option is only available if
the hypervisor was compiled with CONFIG\_XSM enabled.
* `dummy`: this is the default choice. Basic restriction for common deployment
(the dummy module) will be applied. It's also used when XSM is compiled out.
* `flask`: this is the policy based access control. To choose this, the
separated option in kconfig must also be enabled.
* `silo`: this will deny any unmediated communication channels between
unprivileged VMs. To choose this, the separated option in kconfig must also
be enabled.
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.