1. 11 Apr, 2014 5 commits
    • Daniel De Graaf's avatar
      rename various functions referencing dom0 · c248d426
      Daniel De Graaf authored
      
      Most of these functions actually act on the hardware domain, so change
      their names to reflect this.
      
      Command line parameters and variables based on those parameters are
      excluded since those changes would be user-visible, as are any public
      headers.
      Signed-off-by: default avatarDaniel De Graaf <dgdegra@tycho.nsa.gov>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarKeir Fraser <keir@xen.org>
      c248d426
    • Daniel De Graaf's avatar
      rename dom0 to hardware_domain · c86ccbf0
      Daniel De Graaf authored
      
      This should not change any functionality other than renaming the global
      variable.  In a few cases (primarily the domain building code), a local
      variable or argument named dom0 was created and used instead of the
      global hardware_domain to clarify that the domain being used in this
      case is actually domain 0.
      Signed-off-by: default avatarDaniel De Graaf <dgdegra@tycho.nsa.gov>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarChristoph Egger <chegger@amazon.de>
      Acked-by: default avatarKeir Fraser <keir@xen.org>
      c86ccbf0
    • Daniel De Graaf's avatar
      prevent 0 from being used as a dynamic domid · 920641d9
      Daniel De Graaf authored
      
      When the hardware domain is made distinct from dom0, it becomes possible
      to shut down and destroy domain 0 while leaving the hypervisor running.
      If this happens, prevent this domain ID from being considered for
      allocation to a new guest.
      Signed-off-by: default avatarDaniel De Graaf <dgdegra@tycho.nsa.gov>
      Acked-by: default avatarKeir Fraser <keir@xen.org>
      920641d9
    • Daniel De Graaf's avatar
      iommu: Move dom0 setup code to __hwdom_init · 0a1c4db2
      Daniel De Graaf authored
      
      When the hardware domain is split from domain 0, the initialization code
      for the hardware domain cannot be in the __init section, since the
      actual domain creation happens after these sections have been discarded.
      Create a __hwdom_init section designator to annotate these functions,
      and control it using the XSM configuration option for now (since XSM is
      required to take advantage of the security benefits of disaggregation).
      Signed-off-by: default avatarDaniel De Graaf <dgdegra@tycho.nsa.gov>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarKeir Fraser <keir@xen.org>
      0a1c4db2
    • Daniel De Graaf's avatar
      use domid check in is_hardware_domain · 97587d01
      Daniel De Graaf authored
      
      Instead of checking is_privileged to determine if a domain should
      control the hardware, check that the domain_id is equal to zero (which
      is currently the only domain for which is_privileged is true).  This
      allows other places where domain_id is checked for zero to be replaced
      with is_hardware_domain.
      
      The distinction between is_hardware_domain, is_control_domain, and
      domain 0 is based on the following disaggregation model:
      
      Domain 0 bootstraps the system.  It may remain to perform requested
      builds of domains that need a minimal trust chain (i.e. vTPM domains).
      Other than being built by the hypervisor, nothing is special about this
      domain - although it may be useful to have is_control_domain() return
      true depending on the toolstack it uses to build other domains.
      
      The hardware domain manages devices for PCI pass-through to driver
      domains or can act as a driver domain itself, depending on the desired
      degree of disaggregation.  It is also the domain managing devices that
      do not support pass-through: PCI configuration space access, parsing the
      hardware ACPI tables and system power or machine check events.  This is
      the only domain where is_hardware_domain() is true.  The return of
      is_control_domain() may be false for this domain.
      
      The control domain manages other domains, controls guest launch and
      shutdown, and manages resource constraints; is_control_domain() returns
      true.  The functionality guarded by is_control_domain may in the future
      be adapted to use explicit hypercalls, eliminating the special treatment
      of this domain.  It may be reasonable to have multiple control domains
      on a multi-tenant system.
      
      Guest domains and other service or driver domains are all treated
      identically by the hypervisor; the security policy may further constrain
      administrative actions on or communication between these domains.
      Signed-off-by: default avatarDaniel De Graaf <dgdegra@tycho.nsa.gov>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarKeir Fraser <keir@xen.org>
      97587d01
  2. 10 Apr, 2014 17 commits
  3. 09 Apr, 2014 18 commits