Re: [Xen-devel] [PATCH v4 2/2] x86/domctl: Don't pause the whole domain if only getting vcpu state

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.05.18 at 10:24, <aisaila@xxxxxxxxxxxxxxx> wrote:
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -357,20 +357,14 @@ void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct 
> hvm_vmce_vcpu *ctxt)
>      ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
>  }
>  
> -static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h,
> +                               struct vcpu *v)
>  {
> -    struct vcpu *v;
>      int err = 0;
> +    struct hvm_vmce_vcpu ctxt;
>  
> -    for_each_vcpu ( d, v )
> -    {
> -        struct hvm_vmce_vcpu ctxt;
> -
> -        vmce_save_vcpu_ctxt_one(v, &ctxt);
> -        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> -        if ( err )
> -            break;
> -    }
> +    vmce_save_vcpu_ctxt_one(v, &ctxt);
> +    err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
>  
>      return err;
>  }

At the example of this one: The idea of breaking out the patch introducing
the _one() functions was to avoid restructuring in this patch like what you
do here. Any such change not strictly fitting under the title of this patch
should be broken out. There may be multiple steps involved here.

As it stands, the function is now no longer meaningfully different from
vmce_save_vcpu_ctxt_one(), and this pattern recurs. Such redundancy
is undesirable. Together with you now passing v and d (when just v
would suffice) I think you want to further re-structure how handling of
save/restore happens, such that no stub functions like the one here
remain. IOW after having introduced the _one() functions, a second
transformation would be expected to eliminate the original ones, with
(as you do here) the loop moving into the caller.

Jan



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