Re: [PATCH 3/6] xen: add new domctl get_changed_domain

[Juergen Gross <jgross@xxxxxxxx>]

On 04.12.24 11:01, Juergen Gross wrote:
> On 23.10.24 15:10, Juergen Gross wrote:
> > Add a new domctl sub-function to get data of a domain having changed
> > state (this is needed by Xenstore).
> >
> > The returned state just contains the domid, the domain unique id,
> > and some flags (existing, shutdown, dying).
> >
> > In order to enable Xenstore stubdom being built for multiple Xen
> > versions, make this domctl stable.  For stable domctls the
> > interface_version is specific to the respective domctl op and it is an
> > in/out parameter: On input the caller is specifying the desired version
> > of the op, while on output the hypervisor will return the used version
> > (this will be at max the caller supplied version, but might be lower in
> > case the hypervisor doesn't support this version).
> >
> > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> Could I please get some feedback regarding the new stable (sub-)hypercall?
>
> I'd _really_ like to get this series into 4.20.
>
> In the RFC series I suggested a new stable main hypercall, but this wasn't
> liked by Jan. So I used the current approach to make it a sub-op of the
> domctl hypercall, which Jan didn't like either in the current form.
>
> Andrew told me multiple times, he wanted to give some feedback, but hasn't
> done so yet.
>
> I think there are multiple options how to proceed, the following coming to
> my mind:
>
> 1. Use a new stable admin hypercall, similar to the RFC series some time ago.
>     In case this is the preferred option, I'd suggest to make it similar to
>     the current sysctl hypercall, but without the version field. Any not
>     compatible change of a sub-op would need a new sub-op instead.
>
> 2. Use stable domctl (and possibly sysctl in the future) sub-ops like in this
>     patch, but possibly drop the use of the interface version field. Any not
>     compatible change of a stable sub-op would need a new sub-op instead.
>
> I'll set this topic on the agenda of the community call tomorrow in case I
> don't get any feedback allowing to proceed.
So just to have the whole discussion on xen-devel:

In the community call Andrew gave his feedback: he is preferring above
variant 2, with the interface version field required to be 0 for stable
sub-ops.

I'll go this route, while addressing Jan's other comments.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature