Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.02.16 at 17:58, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [PATCH v2 1/2] altp2m: Merge 
> p2m_set_altp2m_mem_access and p2m_set_mem_access"):
>> On 01.02.16 at 16:22, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > It's not like we're short of memory op values.
>> 
>> Are we not? They need to fit in 6 bits (unless we want to play tricks),
>> and numbers up to 27 are already in use.
> 
> Maybe I am confused.  It's hard to make sense of the actual ABI which
> doesn't seem to be documented yet.
> 
> ...
> 
> I have just read the docs some more and found this:
> 
>   /*
>    * To allow safe resume of do_memory_op() after preemption, we need
>    * to know at what point in the page list to resume. For this
>    * purpose I steal the high-order bits of the @cmd parameter, which
>    * are otherwise unused and zero.
>    *
>    * Note that both of these values are effectively part of the ABI,
>    * even if we don't need to make them a formal part of it: A guest
>    * suspended for migration in the middle of a continuation would
>    * fail to work if resumed on a hypervisor using different values.
>    */
>   #define MEMOP_EXTENT_SHIFT 6 /* cmd[:6] == start_extent */
>   #define MEMOP_CMD_MASK     ((1 << MEMOP_EXTENT_SHIFT) - 1)
> 
> Urrrrggh!

No-one said this is nice. And we had an issue already when this
once got widened from (iirc) 4 to 6 bits.

> If we run out of memory_op numbers, can't we just invent a new
> hypercall ?

I suppose we would need to, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel