Re: [Xen-devel] [PATCH v3 2/6] x86/hvm: Provide XEN_DMOP_add_to_physmap

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.01.18 at 10:32, <ross.lagerwall@xxxxxxxxxx> wrote:
> On 01/18/2018 09:24 AM, Jan Beulich wrote:
>>>>> On 12.01.18 at 13:45, <ross.lagerwall@xxxxxxxxxx> wrote:
>>> --- 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?

Best I can think of is XEN_DMOP_move_gfns, but I don't like it
very much, hence I didn't suggest it in my earlier reply.

Jan


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