From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
Subject: Re: [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
Date: Thu, 12 Jan 2012 08:04:34 -0800
Message-ID: <e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
Reply-To: andres@lagarcavilla.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20120112144325.GE8324@aepfle.de>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
List-Id: xen-devel@lists.xenproject.org

> On Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> +++ b/xen/include/public/domctl.h
>
>> +/* Use for teardown/setup of helper<->hypervisor interface for paging,
>> + * access and sharing.*/
>>  struct xen_domctl_mem_event_op {
>>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>>
>> -    union {
>> -        /* OP_ENABLE IN:  Virtual address of shared page */
>> -        uint64_aligned_t shared_addr;
>> -        /* PAGING_PREP IN: buffer to immediately fill page in */
>> -        uint64_aligned_t buffer;
>> -    } u;
>> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> page */
>>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page
>> */
>>
>> -    /* Other OPs */
>> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated
>> on */
>> +    /* For binary backwards compatibility */
>> +    uint64_aligned_t pad;
>>  };
>
> Assuming this struct is routed through libxc, and libxc gets a new
> SONAME for every release, doesnt this mean that every old binary has to
> be recompiled anyway for the new release?
> If so, the padding is not needed.
Agreed, basically. Waiting to hear from tools maintainers about best
approach to libxc.

It seems that there aren't that many users relying on a fixed ABI, so we
can (still, until 4.2) change things. But obviously I want to be careful.

Andres
>
> Olaf
>
>