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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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!

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

Ian.

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