Re: [PATCH v3] xen/public: add comment to struct xen_mem_acquire_resource

[Juergen Gross <jgross@xxxxxxxx>]

On 24.02.22 17:23, Jan Beulich wrote:
> On 24.02.2022 16:41, Juergen Gross wrote:
> > On 24.02.22 16:37, Jan Beulich wrote:
> > > On 24.02.2022 16:24, Juergen Gross wrote:
> > > > --- a/xen/include/public/memory.h
> > > > +++ b/xen/include/public/memory.h
> > > > @@ -662,6 +662,13 @@ struct xen_mem_acquire_resource {
> > > >         * two calls.
> > > >         */
> > > >        uint32_t nr_frames;
> > > > +    /*
> > > > +     * Padding field, must be zero on input.
> > > > +     * In a previous version this was an output field with the lowest
> > > > +     * bit named XENMEM_rsrc_acq_caller_owned. Future versions of this
> > > > +     * interface will not reuse this bit with the field being zero on
> > > > +     * input.
> > > > +     */
> > > >        uint32_t pad;
> > > Did you mean "... being non-zero ..." and "bit" and "field" changing
> > > positions?
> > No, why? The current Linux kernel will set pad (the "field") to zero
> > when doing the hypercall, and it expects the bit to be set or not on
> > return. This means that the bit is reserved for the case that pad
> > was zero on input.
> Hmm, maybe I got confused (but only in part by the wording). The bit is
> fine to use as input. This will mean the field is not zero on input, but
> the way this is worded is somewhat confusing. How about making things
> explicit: "... will not reuse this bit as an output with the field being
> zero on input"? Then
Fine with me.

> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> and I'd be fine making the adjustment while committing.
Thanks,


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature