Re: [PATCH v3 1/2] xen: Add capabilities to get_domain_state

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/07/2025 8:29 am, Jürgen Groß wrote:
> On 23.07.25 09:04, Jan Beulich wrote:
>> On 23.07.2025 08:55, Jürgen Groß wrote:
>>> On 23.07.25 08:43, Jan Beulich wrote:
>>>> On 23.07.2025 08:34, Jürgen Groß wrote:
>>>>> On 23.07.25 08:28, Jan Beulich wrote:
>>>>>> On 22.07.2025 02:19, Jason Andryuk wrote:
>>>>>>> --- a/xen/common/domain.c
>>>>>>> +++ b/xen/common/domain.c
>>>>>>> @@ -195,6 +195,14 @@ static void set_domain_state_info(struct
>>>>>>> xen_domctl_get_domain_state *info,
>>>>>>>             info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
>>>>>>>         if ( d->is_dying == DOMDYING_dead )
>>>>>>>             info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
>>>>>>> +
>>>>>>> +    info->caps = 0;
>>>>>>> +    if ( is_control_domain(d) )
>>>>>>> +        info->caps |= XEN_DOMCTL_GETDOMSTATE_CAP_CONTROL;
>>>>>>> +    if ( is_hardware_domain(d) )
>>>>>>> +        info->caps |= XEN_DOMCTL_GETDOMSTATE_CAP_HARDWARE;
>>>>>>> +    if ( is_xenstore_domain(d) )
>>>>>>> +        info->caps |= XEN_DOMCTL_GETDOMSTATE_CAP_XENSTORE;
>>>>>>>         info->unique_id = d->unique_id;
>>>>>>>     }
>>>>>>
>>>>>> This being a stable sub-op, don't we need a way to indicate to
>>>>>> the caller
>>>>>> _that_ this field has valid data now? When non-zero it's easy to
>>>>>> tell, but
>>>>>> getting back zero is ambiguous.
>>>>>
>>>>> The hypercall sub-op was introduced in this development cycle
>>>>> only, so
>>>>> there is no released Xen hypervisor without the capability setting.
>>>>>
>>>>> In case this patch doesn't make it into 4.21, the case you are
>>>>> mentioning
>>>>> must be handled, of course.
>>>>
>>>> Hmm, yes, this way it's on the edge. As a stable sub-op, someone
>>>> could have
>>>> backported the change, though. IOW (and in general) I wonder
>>>> whether for
>>>> stable sub-ops we shouldn't be pretty strict about functional
>>>> extensions,
>>>> not tying their addition to releases at all.
>>>
>>> Should we really care about downstreams backporting not yet released
>>> functionality?
>>>
>>> Using your reasoning this would mean we'd need to issue XSAs for not
>>> yet
>>> released hypervisor issues of stable interfaces, too. I don't think we
>>> want to do that.
>>
>> To me, the latter doesn't necessarily follow from the former. But
>> anyway, I'm
>> not going to insist, but I wanted the situation to at least be
>> considered. In
>> particular also forward-looking, when we may gain more stable
>> sub-ops. At some
>> point it may turn out necessary to backport such even into upstream
>> branches.
>
> I think it is fine to discuss this situation.
>
> I'd suggest not to support any potential downstream backports of not yet
> released functionality. Consider a new interface being developed in a
> larger
> patch series. In case the series is not being committed in one go,
> would you
> want to support backports of only a part of it? What about fixes of that
> interface in the current release cycle, e.g. due to the use cases
> having been
> committed only some time later uncovering the need to change the
> interface
> to make it safe?

Interfaces cannot be fixed until they're in a RELEASE-* tag.  Anything
else would be absurd position to put upstream Xen into.

Downstreams backporting a not-yet-fixed interface is equivalent to
taking a private ABI into their patchqueue.  They get to keep both
pieces if it goes wrong.

(and I say this as someone who frequently walks this tightrope in the
XenServer patchqueue.)

~Andrew