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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.18 at 15:56, <aisaila@xxxxxxxxxxxxxxx> wrote:
> On Mi, 2018-08-29 at 08:13 -0600, Jan Beulich wrote:
>> > > > On 29.08.18 at 16:02, <aisaila@xxxxxxxxxxxxxxx> wrote:
>> > On Mi, 2018-08-22 at 18:15 +0300, Isaila Alexandru wrote:
>> > > On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote:
>> > > > 
>> > > > If you look at vcpu_hvm in tools/libxc/xc_dom_x86.c it saves
>> > > > the
>> > > > full
>> > > > domain context just to get the CPU and the MTRR state of
>> > > > VCPU#0. Do
>> > > > you think you could switch this code to use the newly
>> > > > introduced
>> > > > machinery to save a single instance of a specific type?
>> > > Sure, I will add a tool patch at the end of the series
>> > Is this urgent to be in this series? If not I will add a new patch
>> > after it is all in. 
>> Considering the problems that there have been with this series,
>> anything to help build confidence in things still working for all
>> cases would help here, so I'm pretty glad Roger thought of this,
>> and while I wouldn't make it as strong as "the series can't go
>> in without this", I'd still much prefer if you too the time.
> 
> I don't think it is possible to use getcontext_partial() in vcpu_hvm()
> because of the need to have a header for xc_domain_hvm_setcontext() and
> the only way to get it is by xc_domain_hvm_getcontext(). There is also
> a comment there that states the same thing
> "/*
>      * Get the full HVM context in order to have the header, it is not
>      * possible to get the header with getcontext_partial, and crafting
> one
>      * from userspace is also not an option since cpuid is trapped and
>      * modified by Xen.
>      */
> "
> I hope I understood the request correctly to start with and if not
> please clarify. 

Hmm, I'm in no way a tools expert, but I agree that this function doesn't
look like it's a good candidate for conversion. I didn't look at it when
Roger pointed you there, and with my previous reply I was only trying
to support the general aspect of Roger's request, not the specific
example. Which means - if there's no better conversion candidate, then
so be it and the series is going to be fine without the extra patch (but
of course we then expect you even more to make sure the best you
can that there are no regressions).

Jan


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