Re: [Xen-devel] [PATCH 08/13] x86: Collect policies together into groups

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.07.18 at 22:55, <andrew.cooper3@xxxxxxxxxx> wrote:
> This is mainly prep work for the following patch, but this specific
> abstraction is also specifically useful for the future auditing logic.
> 
> Not all of msr_vcpu_policy will be interesting from a domain building
> perspective, but some soon-to-appear fields will be (SGX Launch Hash
> specifically).  The exact split of MSRs between domain and vcpu policies is
> internal to Xen and liable to change moving forwards, so treat the two
> structures consistently from the start to avoid problems in the future.

I hope the utility of this grouping will become evident in later
patches.

> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -31,6 +31,29 @@
>  #include <asm/psr.h>
>  #include <asm/cpuid.h>
>  
> +const struct policy_group system_policies[] = {
> +    {
> +        &raw_cpuid_policy,
> +        &raw_msr_domain_policy,
> +        &raw_msr_vcpu_policy,
> +    },
> +    {
> +        &host_cpuid_policy,
> +        &host_msr_domain_policy,
> +        &host_msr_vcpu_policy,
> +    },
> +    {
> +        &pv_max_cpuid_policy,
> +        &pv_max_msr_domain_policy,
> +        &pv_max_msr_vcpu_policy,
> +    },
> +    {
> +        &hvm_max_cpuid_policy,
> +        &hvm_max_msr_domain_policy,
> +        &hvm_max_msr_vcpu_policy,
> +    },
> +};

This being non-static I immediately wonder how correct indexing
into this array is supposed to work. No enum or alike is being added
here.

> --- /dev/null
> +++ b/xen/include/xen/libx86/policies.h
> @@ -0,0 +1,25 @@
> +/* Common data structures and functions consumed by hypervisor and toolstack 
> */
> +#ifndef XEN_LIBX86_POLICIES_H
> +#define XEN_LIBX86_POLICIES_H
> +
> +#include <xen/libx86/cpuid.h>
> +#include <xen/libx86/msr.h>
> +
> +struct policy_group
> +{
> +    struct cpuid_policy *cp;
> +    struct msr_domain_policy *dp;
> +    struct msr_vcpu_policy *vp;
> +};

This is sort of surprising without any libxc change here, and hence
without any use of the type in libxc, but perhaps that'll surface later
on.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel