From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [PATCH] RFC: Use memops for mem paging, sharing,
	and access, instead of domctls
Date: Thu, 26 Jan 2012 12:57:46 +0000
Message-ID: <20120126125746.GC74165@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
	<e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.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>
Content-Disposition: inline
In-Reply-To: <e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
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: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com, ian.campbell@citrix.com, andres@gridcentric.ca, keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
List-Id: xen-devel@lists.xenproject.org

At 08:04 -0800 on 12 Jan (1326355474), Andres Lagar-Cavilla wrote:
> > 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.

Ping?

Tim.