Re: [Xen-devel] [PATCH v4] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>]

On Tue, 2017-10-10 at 06:28 -0600, Jan Beulich wrote:
> > > > +typedef struct xen_hvm_altp2m_set_mem_access_multi
> > +    xen_hvm_altp2m_set_mem_access_multi_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_multi_t);
> 
> Are typedef and handle actually needed anywhere? Otherwise
> please don't add them. Just like recently done for domctl and
> sysctl we should even consider cleaning up the others here.
> 
> Jan
All xen_hvm_altp2m_* structs have also defined the typedef and the
handle. I can remove them for xen_hvm_altp2m_set_mem_access_multi but
this way it will not be in sync with the other xen_hvm_altp2m_*
definitions.

Also, regarding the typedef, I have encountered a possible usage when
trying to generate the XLAT macro for xen_hvm_altp2m_op. Using the
existing way of declaring the structure (union of structs) the enum
corresponding to the union members was not generated. Replacing struct
with the corresponding typedef fixed the issue.
The cause is the condition the ./xen/tools/get-fields.sh uses to
generate the enum (if [ "${kind%%;*}" = union ] ). In our case the kind
variable is something like "struct;struct;struct;..;union" and the
condition is valid only if kind starts with "union", hence the enum is
not generated.
Unfortunately my understanding of this script is quite scarce, so I
cannot propose viable a solution.

Personally I would prefer to keep the definition in sync with the other
 xen_hvm_altp2m_* structs for now and hanlde this issue in a separate
patch for applicable for all definitions.

Best regards,
Petre

> 
> ________________________
> This email was scanned by Bitdefender
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel