Re: [Xen-devel] [PATCH v5] Merge IS_PRIV checks into XSM hooks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.11.12 at 19:28, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> Changes from v4:
>  * Removed patches that have been applied
>  * Rename __do_xsm_op to do_xsm_op
>  * Rebased on current xen-unstable
>  * Policy headers moved under hypervisor
> 
> Changes from v3:
>  * Moved x86-specific sysctls inside #ifdef CONFIG_X86
>  * Removed pt_domain parameter from mmu_update hook when unused
>  * Renamed xsm___do_xsm_op to xsm_do_xsm_op
>  * Added struct domain* argument to arch_do_domctl
>  * Cleaned up mem_event code duplication
> 
> Changes from v2:
>  * Added overall hooks for domctl, sysctl, and platform_hypercall so
>    that new sub-operations are protected by IS_PRIV checks
>  * Reorganized the IS_PRIV additions to dummy.h so they are added in the
>    same patch that removes the IS_PRIV they are replacing
>  * Reworked hooks in the MM hotpath to increase efficiency
>  * Dropped some unneeded XSM hook additions due to do_domctl hook
>  * Dropped the rcu_lock*target_domain_by_id function removal patch
>  * Restore IS_PRIV check in PHYSDEVOP_alloc_irq_vector
>  * Use the existing hook function structure for tmem
> 
> Miscellaneous updates to FLASK:
>     [PATCH 01/19] libxl: introduce XSM relabel on build
>     [PATCH 02/19] flask/policy: Add domain relabel example
>     [PATCH 03/19] arch/x86: add distinct XSM hooks for map/unmap
>     [PATCH 04/19] xsm/flask: Add checks on the domain performing set_target
> 
> IS_PRIV Refactoring:
>     [PATCH 05/19] xsm: Use the dummy XSM module if XSM is disabled
>     [PATCH 06/19] xen: use XSM instead of IS_PRIV where duplicated
>     [PATCH 07/19] xen: avoid calling rcu_lock_*target_domain when an XSM
>     [PATCH 08/19] arch/x86: convert platform_hypercall to use XSM
>     [PATCH 09/19] xen: lock target domain in do_domctl common code
>     [PATCH 10/19] xen: convert do_domctl to use XSM
>     [PATCH 11/19] xen: convert do_sysctl to use XSM
> 
> Additional new/updated hooks:
>     [PATCH 12/19] xsm/flask: add missing hooks
>     [PATCH 13/19] xsm/flask: add distinct SIDs for self/target access
>     [PATCH 14/19] arch/x86: Add missing mem_sharing XSM hooks
>     [PATCH 15/19] arch/x86: use XSM hooks for get_pg_owner access checks
>     [PATCH 16/19] xen: Add XSM hook for XENMEM_exchange
>     [PATCH 17/19] tmem: add XSM hooks
> 
> Other cleanup:
>     [PATCH 18/19] xen/arch/*: add struct domain parameter to
>     [PATCH 19/19] flask: move policy headers into hypervisor

Except for patch 14, once we dealt with the few review comment
I gave on the patches I was explicitly Cc-ed on, feel free to change
the Cc-s into Acked-by-s (unless, of course, you make non-trivial
changes to them down the road); for patches 15 and 18 the acks
would be limited to the x86 (and, for the latter, iommu) pieces.

As to getting the series applied, I suppose that'll be a little difficult,
as it mixes changes to various parts of the tree, and hence no
single maintainer would generally be able to apply the whole series
without respective other parts fully acked by the corresponding
maintainers. Is there a way to either indicate eventual fully
standalone patches, or order/split it so that at least tools side and
hypervisor side changes are separated from one another, or mixed
patches all go at the beginning or end of the series?

Jan


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