[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v14 09/11] x86/domctl: Don't pause the whole domain if only getting vcpu state
>>> On 25.07.18 at 14:14, <aisaila@xxxxxxxxxxxxxxx> wrote: > This patch is focused on moving the for loop to the caller so > now we can save info for a single vcpu instance with the save_one > handlers. > > Signed-off-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> First of all I'd appreciate if this patch was last in the series, after all infrastructure changes have been done. > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -793,6 +793,14 @@ static int hvm_save_cpu_ctxt_one(struct vcpu *v, > hvm_domain_context_t *h) > struct segment_register seg; > struct hvm_hw_cpu ctxt = {}; > > + /* > + * We don't need to save state for a vcpu that is down; the restore > + * code will leave it down if there is nothing saved. > + */ > + if ( v->pause_flags & VPF_down ) > + return 0; > + > + > /* Architecture-specific vmcs/vmcb bits */ > hvm_funcs.save_cpu_ctxt(v, &ctxt); > > @@ -897,13 +905,6 @@ static int hvm_save_cpu_ctxt(struct domain *d, > hvm_domain_context_t *h) > > for_each_vcpu ( d, v ) > { > - /* > - * We don't need to save state for a vcpu that is down; the restore > - * code will leave it down if there is nothing saved. > - */ > - if ( v->pause_flags & VPF_down ) > - continue; Why is this not done in the respective prereq patch? > @@ -1196,7 +1197,7 @@ static int hvm_save_cpu_xsave_states_one(struct vcpu > *v, hvm_domain_context_t *h > unsigned int size = HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum); > int err = 0; > > - if ( !cpu_has_xsave ) > + if ( !cpu_has_xsave || !xsave_enabled(v) ) > return 0; /* do nothing */ > > err = _hvm_init_entry(h, CPU_XSAVE_CODE, v->vcpu_id, size); > @@ -1221,8 +1222,6 @@ static int hvm_save_cpu_xsave_states(struct domain *d, > hvm_domain_context_t *h) > > for_each_vcpu ( d, v ) > { > - if ( !xsave_enabled(v) ) > - continue; Same here. The goal of the prereq patches is that the patch here does not have to touch anything other than the abstract logic. > --- a/xen/arch/x86/hvm/save.c > +++ b/xen/arch/x86/hvm/save.c > @@ -138,9 +138,12 @@ size_t hvm_save_size(struct domain *d) > int hvm_save_one(struct domain *d, unsigned int typecode, unsigned int > instance, > XEN_GUEST_HANDLE_64(uint8) handle, uint64_t *bufsz) > { > - int rv; > + int rv = 0; > hvm_domain_context_t ctxt = { }; > const struct hvm_save_descriptor *desc; > + bool is_single_instance = false; > + uint32_t off = 0; > + struct vcpu *v; > > if ( d->is_dying || > typecode > HVM_SAVE_CODE_MAX || > @@ -148,43 +151,94 @@ int hvm_save_one(struct domain *d, unsigned int > typecode, unsigned int instance, > !hvm_sr_handlers[typecode].save ) > return -EINVAL; > > + if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU && > + instance < d->max_vcpus ) > + is_single_instance = true; It seems quite pointless to allow instance >= d->max_vcpus to progress further. In fact at this point all HVMSR_PER_VCPU instances ought to have a save_one() handler, and hence I'm thinking you could get away without a is_single_instance local variable. > ctxt.size = hvm_sr_handlers[typecode].size; > - if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU ) > + if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU && > + instance == d->max_vcpus ) And as a result I don't understand this addition. I'm afraid the rest of the changes to this function would change too much as a result, so I'm skipping them for now. > @@ -196,7 +250,9 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h) I don't think the remaining changes actually belongs in a patch with a title like the one here has. > struct hvm_save_header hdr; > struct hvm_save_end end; > hvm_save_handler handler; > - unsigned int i; > + hvm_save_one_handler save_one_handler; > + unsigned int i, rc; rc would not normally be of unsigned type. I'm anyway struggling to understand why you introduce the variable. You don't even log its value in the error case(s). > + struct vcpu *v = NULL; Pointless initializer afaict. > @@ -224,11 +280,32 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h) > for ( i = 0; i <= HVM_SAVE_CODE_MAX; i++ ) > { > handler = hvm_sr_handlers[i].save; > - if ( handler != NULL ) > + save_one_handler = hvm_sr_handlers[i].save_one; > + if ( save_one_handler != NULL ) > { > printk(XENLOG_G_INFO "HVM%d save: %s\n", > d->domain_id, hvm_sr_handlers[i].name); Please also log the vCPU ID (perhaps using "HVM %pv save: ...". and also on the error path a few lines down), making this message at the same time distinguishable from ... > - if ( handler(d, h) != 0 ) > + for_each_vcpu ( d, v ) > + { > + rc = save_one_handler(v, h); > + > + if( rc != 0 ) > + { > + printk(XENLOG_G_ERR > + "HVM%d save: failed to save type %"PRIu16"\n", > + d->domain_id, i); > + return -EFAULT; > + } > + } > + } > + else if ( handler != NULL ) > + { > + printk(XENLOG_G_INFO "HVM%d save: %s\n", > + d->domain_id, hvm_sr_handlers[i].name); ... this one and ... > + rc = handler(d, h); > + > + if( rc != 0 ) > { > printk(XENLOG_G_ERR > "HVM%d save: failed to save type %"PRIu16"\n", ... for the error path from this one. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |