On 20.07.23 12:30, Viresh Kumar wrote:
Hello Viresh
Update the definitions in dm_op.h from Xen public header.
I think, it would be good to mention exact Xen version (commit) we are based on.
In general patch looks good to me, just a note.
I compared with Xen's public/hvm/dm_op.h and noticed differences. I understand, this cannot be 100% verbatim copy, because of headers location, emacs magics, GUEST_HANDLE vs XEN_GUEST_HANDLE. The Linux header doesn't contain any aliases the Xen header has for each "struct xen_dm_op_xxx", for example ...
[snip]
+/*
- XEN_DMOP_create_ioreq_server: Instantiate a new IOREQ Server for a
secondary emulator.
- The <id> handed back is unique for target domain. The valur of
- <handle_bufioreq> should be one of HVM_IOREQSRV_BUFIOREQ_* defined in
- hvm_op.h. If the value is HVM_IOREQSRV_BUFIOREQ_OFF then the buffered
- ioreq ring will not be allocated and hence all emulation requests to
- this server will be synchronous.
- */
+#define XEN_DMOP_create_ioreq_server 1
+struct xen_dm_op_create_ioreq_server {
- /* IN - should server handle buffered ioreqs */
- uint8_t handle_bufioreq;
- uint8_t pad[3];
- /* OUT - server id */
- ioservid_t id;
+};
... this one:
typedef struct xen_dm_op_create_ioreq_server xen_dm_op_create_ioreq_server_t;
And "struct xen_dm_op" down the file uses these aliases inside a union.
I assume, we have to diverge here in order to follow a recommendation to avoid typedef'ing structs at [1], am I Ńorrect? Or is there another reason?
I think, it would be good to mention a reason in the description.
[1] https://www.kernel.org/doc/html/v6.4/process/coding-style.html#typedefs