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

[Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>]

On Ma, 2017-09-19 at 00:11 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> 09/18/17 7:05 PM
> > > > >>>
> > On 09/18/2017 06:35 PM, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 12.09.17 at 15:53, <aisaila@xxxxxxxxxxxxxxx> 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.
>
What will be a suitable extend of the current call back system?

Regards,
Alex


________________________
This email was scanned by Bitdefender
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel