On 07.02.2022 12:00, Juergen Gross wrote:
> On 07.02.22 11:46, Jan Beulich wrote:
>> On 07.02.2022 11:36, Juergen Gross wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -662,7 +662,17 @@ struct xen_mem_acquire_resource {
>>> * two calls.
>>> */
>>> uint32_t nr_frames;
>>> - uint32_t pad;
>>> +
>>> + /*
>>> + * OUT - Must be zero on entry. On return this may contain a bitwise
>>> + * OR of the following values.
>>> + */
>>> + uint32_t flags;
>>> +
>>> + /* No longer supported - will be never set */
>>> +#define _XENMEM_rsrc_acq_caller_owned 0
>>> +#define XENMEM_rsrc_acq_caller_owned (1u << _XENMEM_rsrc_acq_caller_owned)
>>
>> I think this goes too far: Neither do we want to re-introduce the
>> #define-s, nor should we re-fix the purpose of the padding field
>> to be OUT (only). All we need to make sure is that the field
>> coming in as zero won't get responded to by setting bit 0 of it.
>> Imo this can only reasonably be done by way of adding a comment.
>> This comment may, in turn, mention XENMEM_rsrc_acq_caller_owned
>> of course.
>
> The kernel could be changed to no longer use that #define before
> updating the header from Xen, but are we really sure there are no
> other users, too?
Pretty sure. And I think in this case it's better to break the build
of consumers (so we're sure they'd notice, assuming they import the
header directly in the first place). It's rather an exceptional case
after all.
Jan
