Re: [PATCH v4 2/6] x86/hvm: Provide XEN_DMOP_relocate_memory

From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [PATCH v4 2/6] x86/hvm: Provide XEN_DMOP_relocate_memory
Date: Wed, 24 Jan 2018 09:20:16 +0000	[thread overview]
Message-ID: <a0f6b03ee1614b65897c7047929472b0@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5A684D6202000078001A1CD0@prv-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 24 January 2018 08:10
> To: Ross Lagerwall <ross.lagerwall@citrix.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Paul Durrant
> <Paul.Durrant@citrix.com>; Wei Liu <wei.liu2@citrix.com>; George Dunlap
> <George.Dunlap@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>;
> Stefano Stabellini <sstabellini@kernel.org>; xen-devel@lists.xen.org; Konrad
> Rzeszutek Wilk <konrad.wilk@oracle.com>; Tim (Xen.org) <tim@xen.org>
> Subject: Re: [PATCH v4 2/6] x86/hvm: Provide
> XEN_DMOP_relocate_memory
> 
> >>> On 23.01.18 at 16:22, <ross.lagerwall@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.lagerwall@citrix.com>
> > Reviewed-by: Paul Durrant <paul.durrant@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 <jbeulich@suse.com>
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel