|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] xen: use domid check in is_hardware_domain
On 07/10/2013 04:30 AM, Jan Beulich wrote: On 09.07.13 at 22:28, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote: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() is 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: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>This isn't correct: I gave my Reviewed-by for the full series; the Acked-by was given only for the two patches touching only code I'm maintainer for. The distinction we're trying to establish is that an ack implies that a maintainer is okay with a certain patch (i.e. a non-maintainer would generally not send ack-s at all), whereas a review means what it says - the patch was reviewed. My logic for applying the Acked-by here was that you had Acked the parts of the patch (in expanded form) that you were listed as maintainer for, so your Ack on the unified patch would actually only be relevant for the x86 and IOMMU parts, requiring additional Acks for the rest of the patch. I had not considered Reviewed-by to be a stronger statement than Acked-by when applying the sign-offs, but after reading the discussion in this thread I agree that Reviewed-by should have been retained (and will on any v3). That said, while I realize that you did this collapsing because you were asked to by George, I'm not certain this was a good move: With one big patch, there's now no way to apply it step by step, as the necessary ack-s trickle in. But the significantly extended description is perhaps outweighing that. Jan While this was my original reason for leaving the patch split up, I don't think partially applying the series is overly helpful - unless there's a risk it will miss 4.4 (which seems unlikely), the patch shouldn't cause issues if it's delayed waiting for all the Acks. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |