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
