Re: [PATCH v3] hypercall/mem: Introduce XENMEM_machphys_compat_mfn_list

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 22/04/14 09:16, Jan Beulich wrote:
>>>> On 18.04.14 at 18:50, <andrew.cooper3@citrix.com> wrote:
>> I am happy for this to live as part of my "migration v2" series, but is
>> presented here for individual review.
> I guess this can go in as soon as it's ready, since even if your save/
> restore re-write doesn't make it we still ought to use this to eliminate
> the bogus workaround in the tools.
>
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -465,6 +465,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
>>   * The zero value is appropiate.
>>   */
>>  
>> +/*
>> + * For a compat toolstack domain, this is identical to
>> + * XENMEM_machphys_mfn_list.
>> + *
>> + * For a non compat toolstack domain, this functions similarly to
>> + * XENMEM_machphys_mfn_list, but returns the mfns making up the compatibility
>> + * m2p table.
>> + */
>> +#define XENMEM_machphys_compat_mfn_list     25
>> +
>>  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
> Is there a strong reason to restrict its visibility to tool stacks? The
> implementation is a simply clone of XENMEM_machphys_mfn_list's,
> which isn't restricted. If the answer is "no", I'd suggest moving
> this addition next to the definition of XENMEM_machphys_mfn_list.
>
> Jan
>

I didn't explicitly intend to limit its visibility.  I was more
concerned with keeping the hypercall numbers in order because it was
non-trivial to work out that 25 was the next free number.

This hypercall is only useful for toolstacks, and indeed only the first
extent, but it is probably better living with the same scope as the other.

~Andrew