[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen/public: partially revert commit 7c7f7e8fba01
On 07.02.22 13:46, Jan Beulich wrote:
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.
Okay, I'll just add a comment regarding the reserved bit then, without
reverting any part of commit 7c7f7e8fba01.
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
|
