>>> Razvan Cojocaru <rcojoc...@bitdefender.com> 09/18/17 7:05 PM >>> >On 09/18/2017 06:35 PM, Jan Beulich wrote: >>>>> On 12.09.17 at 15:53, <aisa...@bitdefender.com> wrote: >>> --- a/xen/arch/x86/domctl.c >>> +++ b/xen/arch/x86/domctl.c >>> @@ -625,6 +625,26 @@ long arch_do_domctl( >>> !is_hvm_domain(d) ) >>> break; >>> >>> + if ( domctl->u.hvmcontext_partial.type == HVM_SAVE_CODE(CPU) && >>> + domctl->u.hvmcontext_partial.instance < d->max_vcpus ) >> >> I have to admit that I'm not in favor of such special casing, even >> less so without any code comment saying why this is so special. >> What if someone else wanted some other piece of vCPU state >> without pausing the entire domain? Wouldn't it be possible to >> generalize this to cover all such state elements? > >There's no reason why all the other cases where this would the possible >shouldn't be optimized. What has made this one stand out for us is that >we're using it a lot with introspection, and the optimization counts. > >But judging by the code reorganization (the addition of >hvm_save_one_cpu_ctxt()), the changes would need to be done on a >one-by-one case anyway (different queries may require different ways of >chaging the code).
But this function addition is precisely what I'd like to avoid in favor of an extension to the existing mechanism using the registered function pointers. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
