[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 2/5] xen: Provide XEN_DMOP_add_to_physmap
- To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
- From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
- Date: Mon, 23 Oct 2017 13:18:33 +0100
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, "Tim \(Xen.org\)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>
- Delivery-date: Mon, 23 Oct 2017 12:18:41 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 10/23/2017 01:03 PM, Paul Durrant wrote:
snip>> +/*
+ * XEN_DMOP_add_to_physmap : Sets the GPFNs at which a page range
appears in
+ * the specified guest's pseudophysical address
+ * space. Identical to XENMEM_add_to_physmap with
+ * space == XENMAPSPACE_gmfn_range.
+ */
+#define XEN_DMOP_add_to_physmap 17
+
+struct xen_dm_op_add_to_physmap {
+ uint16_t size; /* Number of GMFNs to process. */
+ uint16_t pad0;
+ uint32_t pad1;
I think you can lose pad1 by putting idx and gpfn above size rather than below
(since IIRC we only need pad up to the next 4 byte boundary).
Nope, the build fails unless I pad it to an 8 byte boundary. This is
also why I added padding to struct xen_dm_op_pin_memory_cacheattr...
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
