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
Acked-by: Jan Beulich <jbeul...@suse.com>
and I'd be fine making the adjustment while committing.
Jan
