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

[Jürgen Groß <jgross@xxxxxxxx>]

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?


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature