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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.09.17 at 17:28, <aisaila@xxxxxxxxxxxxxxx> wrote:
> 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?

I'm not sure what you expect as an answer here. Something
following the current model, but skipping everything that's
not per-vCPU, and for everything being per-vCPU handling just
the single vCPU of interest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel