xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: konrad wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH 2/6] xl: Implement XENMEM_claim_pages support via 'claim_mode' global config
Date: Mon, 15 Apr 2013 19:20:19 -0400	[thread overview]
Message-ID: <516C8B33.1030404@oracle.com> (raw)
In-Reply-To: <1366018494.4963.27.camel@zakaz.uk.xensource.com>


On 4/15/2013 5:34 AM, Ian Campbell wrote:
> On Fri, 2013-04-12 at 19:03 +0100, Ian Jackson wrote:
>> Ian Jackson writes ("Re: [PATCH 2/6] xl: Implement XENMEM_claim_pages support via 'claim_mode' global config"):
>>> Sorry, I just spotted this.  I think the libxl_defbool_setdefault
>>> shouldn't be there.  The defbool should be initialised to "default",
>>> which can be done by setting it to 0, as per:
>>>
>>>    * To allow users of the library to naively select all defaults this
>>>    * state is represented as 0. False is < 0 and True is > 0.
>>>
>>> in libxl.h.  And since it's a variable of static duration the C
>>> implementation will initialise it to 0.  So just deleting the
>>> setdefault is right.
>>>
>>> The result is that the default is set in libxl, only.
>> Konrad points out that without this, xl can't easily find out whether
>> the claim mode is enabled or not.
> Does it need to know? Is the presence of any non-zero value for a claim
> enough indication for each function which might care to make a local
> decision? At least nothing in this particular patch appears to care what
> libxl's default is.

The issue was that if you try to do libxl_get_defbool and the bool is a 
default - it will
blow up with an assert.
> Is this setting supposed to be global (at either the host or specific
> toolstack level) or is it supposed to be per-domain?
Global
>
> If it is at the toolstack level then shouldn't it be set in the
> libxl_ctx instead of libxl_domain_build_info? If it is per-domain then
> shouldn't there be the possibility of an override in the domain config?
>
> If its supposed to be host wide then that seems to argue for a
> requirement for a libxl specific configuration file, so that all
> toolstacks (at least those which use libxl) can be configured. The xapi
> guys were asking me about the possibility of such settings last week in
> the context of host wide driver domain policy...
>
> Anyway, back to the original point of this mail, assuming my questions
> above haven't made that moot:
>
>> Options are:
>>
>> 1. Leave it as it is, default set in libxl but overridden by
>>     separate setting in xl (perhaps we should add a comment).
>>     Tolerable.
>>
>> 2. Move the default setting out of libxl entirely, so callers
>>     must pass 0 or 1.  (I don't approve of this; we might want
>>     to change the behaviour of naive toolstacks in the future.)
> Agree that this is best avoided.
>
>> 3. Provide a new interface to libxl which allows the claim
>>     default to be retrieved.  Palaver.
> Could incorporate it into whichever of the libxl_*info interfaces seems
> most appropriate. libxl_physinfo contains a lot of the associated free
> memory values, so although claim mode isn't really "phys" perhaps that's
> the best place for it?
>
>> 4. Have xl operations which need to know the default claim mode
>>     set up a dummy domain creation config, ask libxl to set the
>>     defaults in it, and then read out the value.  Very ugly.
> Very.
>
>> Of these I prefer 1.  Opinions ?  Whatever we do needs to be in 4.3.
> 1 is probably the best of the bunch but I note that in that case the
> implementation in xl should be just:
>
>     xl.c:
> 	int claim_mode; /* = 0 */
>
>     xl.c:parse_global_config():
> 	if (!xlu_cfg_get_long (config, "claim_mode", &l, 0))
>              claim_mode = l;
>
>     xl_cmdimpl.c:parse_config_data():
>          libxl_defbool_set_default(&b_info->claim_mode, claim_mode)
>
> i.e. xl's glboal claim mode setting is just a bool, not a defbool.

Yes. That will work too. This was how the earlier versions had it.

I will post a new version when I back in office tomorrow.

Thanks!
>
> Ian.
>

  reply	other threads:[~2013-04-15 23:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10 19:59 [PATCH v15] claim and its friends for allocating multiple self-ballooning guests Konrad Rzeszutek Wilk
2013-04-10 19:59 ` [PATCH 1/6] xc: use XENMEM_claim_pages hypercall during guest creation Konrad Rzeszutek Wilk
2013-04-12 15:16   ` Ian Jackson
2013-04-10 19:59 ` [PATCH 2/6] xl: Implement XENMEM_claim_pages support via 'claim_mode' global config Konrad Rzeszutek Wilk
2013-04-12 15:17   ` Ian Jackson
2013-04-12 17:18   ` Ian Jackson
2013-04-12 18:03     ` Ian Jackson
2013-04-12 18:04       ` Ian Jackson
2013-04-12 19:51       ` Konrad Rzeszutek Wilk
2013-04-12 20:07         ` Konrad Rzeszutek Wilk
2013-04-15  9:26           ` Ian Campbell
2013-04-15  9:34       ` Ian Campbell
2013-04-15 23:20         ` konrad wilk [this message]
2013-04-16  8:50           ` Ian Campbell
2013-04-10 19:59 ` [PATCH 3/6] xl: 'xl info' print outstanding claims if enabled (claim_mode=1 in xl.conf) Konrad Rzeszutek Wilk
2013-04-12 15:18   ` Ian Jackson
2013-04-10 19:59 ` [PATCH 4/6] xc: export outstanding_pages value in xc_dominfo structure Konrad Rzeszutek Wilk
2013-04-12 15:18   ` Ian Jackson
2013-04-10 19:59 ` [PATCH 5/6] xl: export 'outstanding_pages' value from xcinfo Konrad Rzeszutek Wilk
2013-04-12 15:19   ` Ian Jackson
2013-04-10 19:59 ` [PATCH 6/6] xl: 'xl claims' print outstanding per domain claims if enabled (claim_mode=1 in xl.conf) Konrad Rzeszutek Wilk
2013-04-10 20:08   ` Konrad Rzeszutek Wilk
2013-04-12 15:24   ` Ian Jackson
2013-04-12 16:49     ` Konrad Rzeszutek Wilk
2013-04-12 17:10       ` Ian Jackson
2013-04-12 10:55 ` [PATCH v15] claim and its friends for allocating multiple self-ballooning guests George Dunlap
2013-04-12 13:44   ` Konrad Rzeszutek Wilk
2013-04-12 17:20     ` Ian Jackson
2013-04-16 10:19       ` George Dunlap
2013-04-16 10:57         ` Ian Jackson
2013-04-16 10:58           ` George Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2013-03-27 20:55 [PATCH v13] " Konrad Rzeszutek Wilk
2013-03-27 20:55 ` [PATCH 2/6] xl: Implement XENMEM_claim_pages support via 'claim_mode' global config Konrad Rzeszutek Wilk
2013-03-28 16:39   ` Ian Jackson
2013-03-29 19:30     ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=516C8B33.1030404@oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).