Re: [Xen-devel] [PATCH 1/4] xen: use domid check in is_hardware_domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.07.13 at 17:58, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 07/08/2013 10:58 AM, Jan Beulich wrote:
>> All earlier changes can be explained in one way or another to also
>> apply to other than Dom0. This one, however, can't: There can
>> only ever be one domain controling when to shut down the system,
>> and hence I think it is misleading to use is_hardware_domain()
>> here. Or is your targeted abstract model aiming at a single such
>> domain, just perhaps with a domain ID other than zero?
> 
> Yes, that is the model I am using. It splits dom0 into three domains:
> 
> 0. Domain builder: bootstraps the system. 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 be true.
> 1. 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. This is the only domain where is_hardware_domain()
>     is true. The return of is_control_domain() is false for this domain.
> 2. Control domain: manages other domains, controls guest launch/shutdown,
>     manages resource constraints, etc; is_control_domain() returns true.
> 
> This model has a working implementation derived from the work in the XOAR
> paper. It requires a patch on top of these to change the IOMMU setup to
> happen after dom0 starts, and a dedicated domain builder domain.

Okay, in that case

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

for the full series, and for patches 2 and 3 alternatively/additionally

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel