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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.18 at 16:22, <ross.lagerwall@xxxxxxxxxx> 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@xxxxxxxxxx>
> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> ---
> 
> 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 <jbeulich@xxxxxxxx>

Jan


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