On 01/18/2018 09:24 AM, Jan Beulich wrote:
On 12.01.18 at 13:45, <ross.lagerw...@citrix.com> wrote:--- a/xen/arch/x86/hvm/dm.c +++ b/xen/arch/x86/hvm/dm.c @@ -640,6 +640,42 @@ static int dm_op(const struct dmop_args *op_args) break; }+ case XEN_DMOP_add_to_physmap:+ { + struct xen_dm_op_add_to_physmap *data = + &op.u.add_to_physmap; + struct xen_add_to_physmap xatp = { + .domid = op_args->domid, + .size = data->size, + .space = XENMAPSPACE_gmfn_range, + .idx = data->src_gfn, + .gpfn = data->dst_gfn, + }; + + if ( data->pad ) + { + rc = -EINVAL; + break; + } + + if ( xatp.size != data->size ) + { + rc = -EOVERFLOW; + break;I guess this is fine for now, but clearly not really necessary, as the continuation logic could take care of the situation. Please add a comment to this effect.
Oh, I didn't think of using the continuation logic for that. I'll use it then.
--- a/xen/include/public/hvm/dm_op.h +++ b/xen/include/public/hvm/dm_op.h @@ -368,6 +368,24 @@ struct xen_dm_op_remote_shutdown { /* (Other reason values are not blocked) */ };+/*+ * XEN_DMOP_add_to_physmap : Sets the GFNs at which a page range appears in + * the specified guest's 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 { + /* Number of GFNs to process. */ + uint32_t size; + uint32_t pad; + /* Starting GFN of the source mapping page(s). */ + uint64_aligned_t src_gfn; + /* Starting GFN where the source mapping page(s) should appear. */ + uint64_aligned_t dst_gfn; +};So why again is this "add-to-physmap"? It's moving memory around, isn't it? The comment also could be more clear in this regard. Everything else looks fine to me now.
Do you have a preference for what to call it? -- Ross Lagerwall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
