[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 06/25 v7] xen/arm: vpl011: Add a new domctl API to initialize vpl011
>>> On 21.08.17 at 12:28, <bhupinder.thakur@xxxxxxxxxx> wrote: > Hi Jan, > > On 7 August 2017 at 14:44, Jan Beulich <jbeulich@xxxxxxxx> wrote: >>>>> Bhupinder Thakur <bhupinder.thakur@xxxxxxxxxx> 08/07/17 10:55 AM >>> >>>@@ -1148,6 +1149,24 @@ struct xen_domctl_psr_cat_op { >>>uint32_t target; /* IN */ >>>uint64_t data; /* IN/OUT */ >>>}; >>>+ >>>+struct xen_domctl_vuart_op { >>>+#define XEN_DOMCTL_VUART_OP_INIT 0 >>>+ uint32_t cmd; /* XEN_DOMCTL_VUART_OP_* */ >>>+ domid_t console_domid; /* IN */ >>>+#define XEN_DOMCTL_VUART_TYPE_VPL011 0 >>>+ uint32_t type; /* IN - type of vuart. >>>+ * Currently only vpl011 supported. >>>+ */ >>>+ xen_pfn_t gfn; /* IN - guest gfn to be used as a >>>+ * ring buffer. >>>+ */ >>>+ evtchn_port_t evtchn; /* OUT - remote port of the event >>>+ * channel used for sending >>>+ * ring buffer events. >>>+ */ >>>+}; >> >> Please try to limit the amount of padding needed and make all remaining >> padding fields explicit. That should then also make obvious that using >> xen_pfn_t in domctl.h is not a good idea (the existing uses are bogus too >> afaict - in the getpageframeinfo3 case the handler deals with the differing >> width between 32- and 64-bit callers, and the cacheflush one is fine right >> now only because it's ARM-only). > > Please correct me if I understood your comment wrongly. > > I believe you are referring to re-ordering the fields in the above > structure so that the structure size is minimised. Yes. > Should I use type as unsigned long instead of xen_pfn_t in this structure? No, uint64_aligned_t is what you want. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |