This
adds support to the hypervisor for the creation of a hardware
domain
distinct from domain 0, allowing further disaggregation of the
duties
of domain 0. The commit message for patch 1 contains a more
complete
description of the distinction between the hardware domain and
control
domain(s). Making the hardware domain distinct from domain 0
allows
it to be further de-privileged using an XSM policy: the hardware
domain
does not need to be permitted access to create or modify other
domains
in order to act as a device backend for them.
Changes since v2:
- Rename and move CONFIG_LATE_HWDOM declaration to asm-x86/config.h
- Move alloc_dom0_vcpu0 prototype change from patch 5 to 4
- Also
rename nmi_{dom0 => hwdom}_report
- Add help/documentation for xl
destroy -f
Changes since v1:
- More complete conversion to
is_hardware_domain (convert "== dom0")
- Rename "dom0" global
variable and associated functions
- Avoid locating the
hardware_domid variable in x86-only code
- Require using "xl destroy
-f 0" to destroy domain 0 to retain the
existing guard against
accidental attempts to destroy domain 0 that
will still cause
disruption of the platform.
- Add an XSM permission check so that
the security label of the
hardware domain can be limited by the
policy.
- Rebase against updated xen/staging
[PATCH 1/7] xen:
use domid check in is_hardware_domain
[PATCH 2/7] xen/iommu: Move
dom0 setup to __hwdom_init
[PATCH 3/7] xen: prevent 0 from being used
as a dynamic domid
[PATCH 4/7] xen: rename dom0 to hardware_domain
[PATCH
5/7] xen: rename various functions referencing dom0
[PATCH 6/7] xen:
Allow hardare domain != dom0
[PATCH 7/7] tools/libxl: Allow dom0 to
be destroyed
