> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 24 January 2018 08:10 > To: Ross Lagerwall <ross.lagerw...@citrix.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; Paul Durrant > <paul.durr...@citrix.com>; Wei Liu <wei.l...@citrix.com>; George Dunlap > <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; > Stefano Stabellini <sstabell...@kernel.org>; xen-de...@lists.xen.org; Konrad > Rzeszutek Wilk <konrad.w...@oracle.com>; Tim (Xen.org) <t...@xen.org> > Subject: Re: [PATCH v4 2/6] x86/hvm: Provide > XEN_DMOP_relocate_memory > > >>> 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.
FAOD, I am. Paul > > > --- 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