Re: [Xen-devel] [PATCH 2/2] xen: Drop DOMCTL_getmemlist and xc_get_pfn_list()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.01.18 at 14:29, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/01/18 13:01, Jan Beulich wrote:
>>>>> On 22.01.18 at 13:52, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 22/01/18 12:41, Jan Beulich wrote:
>>>>>>> On 19.01.18 at 20:19, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> --- a/xen/include/public/domctl.h
>>>>> +++ b/xen/include/public/domctl.h
>>>>> @@ -1117,7 +1117,7 @@ struct xen_domctl {
>>>>>  #define XEN_DOMCTL_pausedomain                    3
>>>>>  #define XEN_DOMCTL_unpausedomain                  4
>>>>>  #define XEN_DOMCTL_getdomaininfo                  5
>>>>> -#define XEN_DOMCTL_getmemlist                     6
>>>>> +/* #define XEN_DOMCTL_getmemlist                  6 Obsolete */
>>>>>  /* #define XEN_DOMCTL_getpageframeinfo            7 Obsolete - use 
>>> getpageframeinfo3 */
>>>>>  /* #define XEN_DOMCTL_getpageframeinfo2           8 Obsolete - use 
>>> getpageframeinfo3 */
>>>>>  #define XEN_DOMCTL_setvcpuaffinity                9
>>>> Just like mentioned upon someone else's recent submission to
>>>> remove a domctl sub-op: You want to bump the interface version
>>>> (remember that the bump done for the shim doesn't count as long
>>>> as there is a possible plan to make that other recent commit part
>>>> of a 4.10.x stable release).
>>> There has already been a version bump for 4.11.
>> I know, hence the longer explanation, which I had given also
>> when the shim series was first posted: If that domctl change is
>> to be backported to 4.10, interface version 0xf will be burnt
>> for _just that change_. That other bump is sufficient only when
>> there is no plan whatsoever to backport the earlier change.
> 
> If that change is backported to 4.10, that is the time to burn another
> interface version.  Not in this patch.

Not if the backport happens only after 4.11 has shipped. And
even it the backport happened earlier, we're liable to forget if
we don't do it now. If there was just a remote chance of that
backport to happen, I probably wouldn't insist, but aiui there's
a pretty determined plan to do so.

I also find it strange that you didn't respond back when I had
first outlined this extra requirement.

> Also, this demonstrates the inherent problems with the interface
> version.  This trick can only ever be played on the most recently
> released branch.  It is a dire trainwreck in terms of versioning, and
> serves only to make it almost impossible to make changes to an installed
> system.

It's not optimal, but I have yet to see a proposal of a mechanism
that's more flexible than this one, but provides at least the same
minimal protection against mismatches.

As to changes to an installed system - the domctl interface should
be in sufficiently usable a shape that such won't be necessary. Or
in the worst case new sub-ops could always be added.

>>>> Plus I again question whether
>>>> "Obsolete" is an appropriate description for something that's no
>>>> longer part of the interface (rather than just being suggested to
>>>> no longer be used). Is there any point in keeping the old sub-op
>>>> as a comment in the first place?
>>> To avoid the number being reused.  It also serves as a marker to locate
>>> the change which removed the hypercall if anyone is doing archaeology in
>>> the future.
>> The number getting re-used with a higher interface version is no
>> problem at all, afaics.
> 
> Yes it is.  do_domctl() (which inserts the domctl version) is remote
> from the choice of op to use, so reusing numbers means that the language
> subs around libxc can issue completely erroneous hypercalls without
> suffering a build or version failure.  (Again, see trainwreck of a
> versioning scheme.)

do_domctl() itself shouldn't be available for use outside of libxc.
And the actual libxc wrapper for a removed sub-op would be
unavailable in the shared object matching the underlying Xen.

Jan


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