From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olaf Hering <olaf@aepfle.de>
Subject: Re: libxl/xl memory paging/sharing/ballooning/etc
	proposal.
Date: Thu, 15 Mar 2012 16:14:25 +0100
Message-ID: <20120315151424.GA7421@aepfle.de>
References: <1331805673.26979.59.camel@zakaz.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>
Content-Disposition: inline
In-Reply-To: <1331805673.26979.59.camel@zakaz.uk.xensource.com>
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 Campbell <Ian.Campbell@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Andres Lagar-Cavilla <andres@lagarcavilla.org>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Thu, Mar 15, Ian Campbell wrote:


> low level libxl interface
> -------------------------
> 
> It is expected that toolstacks primary user interface will be via the
> above high level interface. The lowlevel interface is provided in order
> to allow implementation of memory policy actors using libxl and to allow
> toolstacks to optionally provide an interface for expert users to shoot
> themselves in the foot with ( ;-) )
> 
> libxl_domain_(set|get)_balloon_target(ctx, domid, target_memkb, relative, enforce):
>         
>         Read/write /local/domain/X/memory/target to control the in guest
>         balloon driver. This is basically the existing
>         libxl_domain_memory_target with a new name
>                 
>         As before this is a request to the guest balloon driver to try
>         and use this much actual RAM. This is an existing guest
>         interface which we cannot change.
> 
> libxl_domain_(set|get)_paging_target(ctx, domid, target_memkb, relative)
> 
>         Read/write whichever XS path controls the xenpaging daemon's
>         target. (Olaf?). I think this path should not be
>         under /local/domain since it should not be guest visible
>         (probably it already isn't).

Its currently /local/domain/X/memory/target-tot_pages, but can still be
changed if needed.

>         It is an error to call this for a PV guest (ERROR_??) for a
>         guest which does not have paging enabled
>         (ERROR_PAGING_DISABLED?).

Error is ok.

> libxl_domain_(enable|disable)_paging(ctx, domid)
> 
>         Idempotently starts or stops the xenpaging daemon for a domain.

In what context should this run?
In case of 'xl $enable_paging' it would be good if this acts as a
trigger for the xl monitoring process, so that the pager is a child of
the monitoring process.

Olaf