>>> On 23.01.18 at 16:22, <ross.lagerw...@citrix.com> wrote: > Provide XEN_DMOP_relocate_memory, a limited version of > XENMEM_add_to_physmap to allow a deprivileged QEMU to move VRAM when a > guest programs its BAR. It is equivalent to XENMEM_add_to_physmap with > space == XENMAPSPACE_gmfn_range. > > Signed-off-by: Ross Lagerwall <ross.lagerw...@citrix.com> > Reviewed-by: Paul Durrant <paul.durr...@citrix.com> > --- > > Changed in v4: > * Renamed add_to_physmap to relocate_memory. > * Instead of checking for overflow, handle using continuation.
Strictly speaking at least the latter change should have resulted in Paul's R-b to be dropped. But I'm pretty sure he's happy for it to be kept. > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -368,6 +368,23 @@ struct xen_dm_op_remote_shutdown { > /* (Other reason values are not blocked) */ > }; > > +/* > + * XEN_DMOP_relocate_memory : Relocate GFNs for the specified guest. > + * Identical to XENMEM_add_to_physmap with > + * space == XENMAPSPACE_gmfn_range. > + */ > +#define XEN_DMOP_relocate_memory 17 > + > +struct xen_dm_op_relocate_memory { > + /* Number of GFNs to process. */ > + uint32_t size; > + uint32_t pad; > + /* Starting GFN to relocate. */ > + uint64_aligned_t src_gfn; > + /* Starting GFN where GFNs should be relocated. */ > + uint64_aligned_t dst_gfn; > +}; Sadly additions after the initial introduction of dmop have been done without IN / OUT annotations, so I assume you not noticing such no neighboring declarations lead to you not adding any such here. I think we want to clarify though that due to the way the continuation logic above works, all fields are IN/OUT, with their ultimate OUT state undefined. I don't see a major problem adding a suitable comment while committing. With that added Reviewed-by: Jan Beulich <jbeul...@suse.com> Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel