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. Jan
