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. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
