From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH v2 1/2] altp2m: Merge
 p2m_set_altp2m_mem_access and p2m_set_mem_access
Date: Mon, 01 Feb 2016 10:03:40 -0700
Message-ID: <56AF9DFC02000078000CD256@prv-mh.provo.novell.com>
References: <1454014688-25060-1-git-send-email-tlengyel@novetta.com>
	<56AB552202000078000CC5E5@prv-mh.provo.novell.com>
	<CAD33N+6NoGPTg7E9oUPxbcESb9ZaCP5+OJ538-Ymf535=u9pLw@mail.gmail.com>
	<56AB9F3102000078000CC78F@prv-mh.provo.novell.com>
	<CAD33N+50n1ozKhbYv5i8uOQO3m7Kjk3drdsHm+srn=zRGuqqQQ@mail.gmail.com>
	<56ABA5CA02000078000CC820@prv-mh.provo.novell.com>
	<1454337922.28781.102.camel@citrix.com>
	<22191.30790.516507.496745@mariner.uk.xensource.com>
	<56AF985A02000078000CD1FA@prv-mh.provo.novell.com>
	<22191.36554.310417.255788@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1aQHtE-0003xd-Mq
	for xen-devel@lists.xenproject.org; Mon, 01 Feb 2016 17:03:48 +0000
In-Reply-To: <22191.36554.310417.255788@mariner.uk.xensource.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Razvan Cojocaru <rcojocaru@bitdefender.com>, StefanoStabellini <stefano.stabellini@eu.citrix.com>, George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, Tamas Lengyel <tlengyel@novetta.com>, xen-devel@lists.xenproject.org, KeirFraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

>>> On 01.02.16 at 17:58, <Ian.Jackson@eu.citrix.com> 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@eu.citrix.com> 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